Most teams already run scanners.
Many still miss XSS.
That’s because XSS is rarely a simple input problem.
It’s a data-flow and context problem.
Red teams don’t hunt for “XSS payloads.”
They hunt for where trust breaks silently.
How Red Teams Think Differently
Automated tools ask:
“Is input reflected?”
Red teams ask:
“Where does user-controlled data travel, transform, and finally execute?”
That shift is where hidden XSS lives.
What Automated Scanners Commonly Miss
Scanners struggle with:
1. Multi-step workflows
2. JavaScript-rendered content
3. Role-based views (admin vs user)
4. Internal tools and dashboards
5. Data shown long after it was entered
XSS often appears outside the original request.
Red Team Discovery Techniques
1. Tracing Data Across the Application
Red teams track user data through:
1. APIs
2. Background jobs
3. Logs
4. Caches
5. Admin interfaces
Practical red-team question:
“Where will this value appear later, not now?”
Example: Stored XSS via Indirect Display
1. User submits profile data
2. Data is stored safely
3. Later rendered in an admin dashboard
4. Context changes → encoding fails
This is why scanners miss it.
Pseudo-Logic
INPUT -> DATABASE -> API -> ADMIN UI
If encoding happens only at INPUT
But execution happens at UI
Risk exists
2. Context Testing, Not Payload Testing
Red teams focus on rendering context:
1. HTML body
2. HTML attributes
3. JavaScript variables
4. JSON responses
5. Client-side templates
Same data. Different danger.
Safe Conceptual Example
IF data is placed inside JavaScript
THEN HTML encoding is not enough
Context-specific handling is required
3. Client-Side (DOM) Trust Analysis
Modern apps move logic to the browser.
Red teams inspect:
1. URL parameters
2. Hash fragments
3. LocalStorage / SessionStorage
4. JavaScript routing logic
If JavaScript builds the page dynamically,
XSS may exist without touching the server.
Real Example: DOM-Based XSS
1. Page reads data from URL
2. JavaScript inserts it into DOM
3. No server logs show abuse
4. User executes attacker-controlled logic
This is invisible to many scanners.
Practical Tools Red Teams Use
Client & Browser Assessment
1. Browser Debugging Tools - View DOM and JavaScript execution sequences.
2. React/Vue.js Debugging Tools - View rendering paths of components.
Request and Data Flow Analysis
1. Burp Suite in Manual Mode - View and change requests.
2. Postman - Test the backend APIs that provide data for the frontend.
Validation & Detection
1. OWASP ZAP – Baseline scanning and traffic capture
2. Dalfox – Pattern-based XSS detection (used cautiously)
Configuration & Headers
1. Mozilla Observatory
2. SecurityHeaders.com
Tools find clues.
Humans decide impact.
Practical Defensive Code Examples
1. Output Encoding (Server Side – Conceptual)
Always encode data at the point of output,
not just when it enters the system.
Example (Conceptual JavaScript Template Use)
// Rendering example
element.textContent = userInput;
// NOT innerHTML
2. Context-Aware Encoding Rule
HTML context -> HTML encode
Attribute -> Attribute encode
JavaScript -> JavaScript-safe encoding
URL -> URL encoding
One encoding does not fit all.
3. Content Security Policy (CSP) Example
Content-Security-Policy:
default-src 'self';
script-src 'self';
object-src 'none';
CSP doesn’t fix XSS,
but it limits damage when something slips through.
4. Client-Side Safety Check (Conceptual)
// Never trust URL parameters directly
const value = getParameter();
renderSafely(value);
The danger is not JavaScript —
it’s unchecked assumptions.
Why Do Red Teams Avoid Obvious Payloads?
1. Simple payloads (WAF rules) - trigger WAF rules and alerts your defender, but they also will miss any logic flaws.
2. Instead of using simple payloads, red teams will look at the data flow through the application to identify edge cases, exploit assumptions and stay stealthy.
3. The most dangerous XSS is the most unassuming.
Lessons Learned for Defenders
1. Originating from scanners shows a defect of being distorted or not found.
2. Consider the full journey a user takes when using a site, not just a few pages.
3. Admin and internal tools are high risk and should be treated as such.
4. Client-side code should be treated with the same seriousness as server-side code.
5. Data paths should be considered when determining a secure method of handling data and not just the input fields for such data.
If you do not know the direction of data, you cannot provide security for that data.
Takeaways
1. Red teams, when looking to identify XSS, do so by tracking data and not by looking at the payload.
2. When the context changes, there may be additional hidden paths for execution.
3. Many times, we can find high-impact XSS in client-side logic.
4. Tools will help you, but only by the effort of the human behind the tool.
5. It is because of the complex nature of trust that XSS continues to be an issue.
