React JS vs Old Tools What Changed for Ethical Hackers

Old web recon looked like this:

1. Crawl the site with a proxy
   → every link is a real HTTP request
   → every form posts to /login, /register, /search

2. View-source on every page
   → find hidden fields, comments, endpoints

3. Directory brute-force
   → gobuster / dirb for /admin, /backup, /api

4. Fuzz every input
   → SQLi, XSS, command injection payloads
   → response reflects the input if vulnerable

5. Check cookies, headers, redirects
   → session handling, open redirects, missing flags

This worked because the server rendered everything.
Every route was a real server endpoint.

Old tools that STILL work on React apps:

☐ Burp Suite as an HTTP proxy
   → every fetch() call is still an HTTP request
   → intercept, replay, modify, fuzz

☐ curl / Postman
   → directly hit API endpoints
   → often the fastest way to reproduce a bug

☐ gobuster for API paths
   → /api/v1/users, /api/internal/...
   → but only if you know the API prefix

☐ Headers and cookies
   → CSRF, CORS, missing flags still matter

☐ Payload fuzzing
   → SQLi, XSS, SSRF payloads still work
   → they just go to API endpoints, not HTML forms

The tools did not become useless.
The target moved.

What changed when apps moved to React:

☐ The page is a shell — the data lives behind APIs
☐ "View-source" shows an empty div and one script tag
☐ Routes like /admin are UI-only — the server may not know them
☐ Authorization must be checked on the API, not the route
☐ Tokens (JWT) often live in localStorage
☐ Source maps may expose the original code
☐ Hidden features exist in the JS bundle, not in HTML
☐ GraphQL endpoints replace REST in many apps
☐ CSRF is less common but still possible with cookie auth
☐ XSS moves to dangerous render paths, not reflected forms

The bug bounty entry point moved from "URL and forms"
to "network tab and JS bundle".

What did NOT change (still works the same way):

☐ SQL injection — if the API is badly built
☐ XSS — if React is bypassed with dangerouslySetInnerHTML
☐ Broken access control — if the API does not check the user
☐ IDOR — if the API returns another user's data by ID
☐ Sensitive data exposure — if the API returns too much
☐ Weak auth — if JWT is not validated or expires badly
☐ Rate limiting — if you can brute-force the API
☐ Open redirects — if the app trusts a ?next= parameter
☐ CORS misconfig — if the API trusts any origin
☐ SSRF — if the server fetches URLs from user input

React did not fix the OWASP Top 10.
It only changed the attack surface you use to reach them.

# Step 1 — open DevTools → Network
# Reload the app, filter by "JS"
# You will see something like:
#   /static/js/main.4f2a1c.js
#   /static/js/2.a91b12.chunk.js
#   /static/js/runtime-main.js

# Step 2 — download the main bundle
curl -O https://target.com/static/js/main.4f2a1c.js

# Step 3 — beautify it
# Use jsbeautifier.org or prettier in VS Code

# Step 4 — search for useful strings
grep -oE '"/api/[^"]+"' main.js | sort -u
grep -oE 'https?://[^"]+' main.js | sort -u
grep -iE 'admin|internal|debug|feature' main.js

# Step 5 — look for feature flags or hidden routes
# Many React apps ship admin code that is hidden
# only by a client-side condition

# Source maps are often shipped by mistake
# Try the standard paths:

curl -I https://target.com/static/js/main.4f2a1c.js.map
curl -I https://target.com/static/js/main.js.map

# If you get a 200, you just downloaded
# the original, unminified source code.

# Why this is a real finding:
☐ Original variable names are visible
☐ Internal API paths are revealed
☐ Comments may contain TODO or debug notes
☐ Third-party tokens may be embedded
☐ Business logic becomes readable

# Severity depends on what is exposed.
# In many bug bounty programs, exposed source maps
# are accepted as a low/medium finding.

# Reporting tip: show the exact URL and one
# snippet from the .map file as proof.

An ethical hacker's React-era toolkit:

Browser side
☐ Chrome DevTools — Network, Sources, Application
☐ React DevTools — component tree, props, state
☐ FoxyProxy — toggle Burp proxy quickly
☐ Wappalyzer — confirm the stack

Proxy / interception
☐ Burp Suite Community or Pro
☐ OWASP ZAP (open source alternative)

JS analysis
☐ jsbeautifier.org or Prettier
☐ Source mapper (to read .map files)
☐ grep / ripgrep for endpoint strings

API testing
☐ Postman or Insomnia
☐ curl for quick replay
☐ GraphiQL for GraphQL introspection

Token analysis
☐ jwt.io — decode JWTs
☐ jwt_tool — test for alg:none, weak secrets

Automation
☐ Nuclei — exposed .map, common API leaks
☐ ffuf — API path fuzzing

You do not need all of these.
Pick one from each category and master it.

Quick wins that catch real bugs fast:

1. Open DevTools → Network → filter "fetch/XHR"
   → every API call is here
   → copy as curl and replay in Postman

2. Open DevTools → Sources → search "api/"
   → hidden endpoints show up immediately

3. Try /main.js.map on the app root
   → if 200, source code is leaked

4. Decode the JWT in Application → Local Storage
   → check expiry, "alg", role claims

5. Try /graphql with { __schema { types { name } } }
   → if introspection is on, the whole API is exposed

6. Change the "id" in an API response URL
   → /api/users/123 → /api/users/124
   → if you get another user's data, that's IDOR

These six checks catch a huge share of React app bugs.
Do them before you start fuzzing.

// 1. dangerouslySetInnerHTML — still dangerous
// If userInput comes from an API and is not sanitised,
// this is a direct XSS.

<div dangerouslySetInnerHTML={{ __html: userInput }} />

// 2. javascript: URLs — click-based XSS
// The browser executes javascript: URLs on click.

<a href={`javascript:${userInput}`}>Click me</a>

// 3. Markdown renderers that allow HTML
// react-markdown is safe by default — but if you add
// rehype-raw or allow HTML, it becomes vulnerable.

<ReactMarkdown rehypePlugins={[rehypeRaw]}>
  {userContent}
</ReactMarkdown>

// 4. Direct DOM writes bypass React entirely
ref.current.innerHTML = userInput;

// These are the places XSS still works in React.
// The default escaping does not help here.

// Safe-by-default patterns in React

// 1. Plain JSX interpolation is escaped
<p>{userInput}</p>

// 2. Attribute interpolation is escaped
<img src={safeUrl} alt={userInput} />

// 3. Sanitise before dangerouslySetInnerHTML
import DOMPurify from "dompurify";
<div dangerouslySetInnerHTML={{
  __html: DOMPurify.sanitize(userInput)
}} />

// 4. Validate URL protocols before using in href
const safe = userInput.startsWith("http") ? userInput : "#";

// 5. Avoid raw HTML renderers on user content
// If you must render markdown, use a safe renderer
// without rehype-raw.

// The pattern to remember:
// React escapes by default — but the developer can turn it off.
// Every dangerouslySetInnerHTML is a place to look.

# List all JS files loaded by the app
curl -s https://target.com | grep -oE 'src="[^"]+\.js"' | sort -u

# Download the main bundle
curl -sO https://target.com/static/js/main.js

# Search for API endpoints
grep -oE '"/api/[^"]+"' main.js | sort -u

# Search for feature flags
grep -oE '"feature_[^"]+"' main.js | sort -u

# Try to fetch the source map
curl -I https://target.com/static/js/main.js.map

# Try common API prefixes
for p in api v1 api/v1 internal admin; do
  curl -o /dev/null -s -w "%{http_code} $p\n" \
    https://target.com/$p/
done

# Copy any XHR from DevTools as cURL, then replay.
# Example: a typical authenticated API call

curl -X POST https://target.com/api/v1/orders \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"productId":123,"quantity":1}'

# Now test for broken access control:
# change the productId, or drop the auth header,
# or use a low-priv token

curl -X POST https://target.com/api/v1/orders \
  -H "Authorization: Bearer $LOW_PRIV_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"productId":999,"quantity":1}'

# Also try:
# - remove Authorization entirely
# - send a token with alg: none
# - send a token for a different user
# - change the user id in the URL

Every API call is a test case.
Do not only test the UI.