Cross-Site Scripting: Stored, Reflected, and DOM

How XSS is Created

The topic 'How XSS is Created' is a central part of working on XSS testing. It is recommended to break it down into three questions: What is the input, what decision do you want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool use without understanding the goal.

In practice, record context, encoding, CSP, stored/reflected/DOM, sanitization, compare to expected behavior, and define at least one Pivot. The result should be verifiable by another analyst, including limitations and next steps.

Reflected and Stored

The topic 'Reflected and Stored' is a central part of working on XSS testing. It is recommended to break it down into three questions: What is the input, what decision do you want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool use without understanding the goal.

In practice, record context, encoding, CSP, stored/reflected/DOM, sanitization, compare to expected behavior, and define at least one Pivot. The result should be verifiable by another analyst, including limitations and next steps.

DOM-based XSS

The topic 'DOM-based XSS' is a central part of working on XSS testing. It is recommended to break it down into three questions: What is the input, what decision do you want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool use without understanding the goal.

In practice, record context, encoding, CSP, stored/reflected/DOM, sanitization, compare to expected behavior, and define at least one Pivot. The result should be verifiable by another analyst, including limitations and next steps.

Context and Encoding

The topic 'Context and Encoding' is a central part of working on XSS testing. It is recommended to break it down into three questions: What is the input, what decision do you want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool use without understanding the goal.

In practice, record context, encoding, CSP, stored/reflected/DOM, sanitization, compare to expected behavior, and define at least one Pivot. The result should be verifiable by another analyst, including limitations and next steps.

CSP, Remediation, and Retest

Professional XSS testing begins with success and failure conditions. Define a positive case, a negative case, a boundary case, and similar legitimate activity. This way, both False Negatives and False Positives can be identified.

In an authorized environment, use minimal action that proves the claim without causing damage. Save Input, Output, time, and version, and after remediation, perform a Retest using the same scenario and also check for Regression on nearby functions.

Unique Testing Focuses

For this topic, it is recommended to build a focused evidence map in advance. The main testing focuses are: context, encoding, CSP, stored/reflected/DOM, sanitization, sink/source. The list is not an automatic Checklist; each item is chosen because it can link an entity, action, and time, or explain legitimate behavior.

• context: Define the expected value, what would be considered anomalous, and what additional source would confirm the finding.
• encoding: Define the expected value, what would be considered anomalous, and what additional source would confirm the finding.
• CSP: Define the expected value, what would be considered anomalous, and what additional source would confirm the finding.
• stored/reflected/DOM: Define the expected value, what would be considered anomalous, and what additional source would confirm the finding.
• sanitization: Define the expected value, what would be considered anomalous, and what additional source would confirm the finding.
• sink/source: Define the expected value, what would be considered anomalous, and what additional source would confirm the finding.

When one of the focuses is unavailable, document the gap and choose an alternative. For example, if a Process identifier is unstable, you can use time, Host, User, and Parent; if a Payload is encrypted, use Metadata, volume, frequency, and TLS/DNS context.

Recommended Workflow

1. Define a Scope and one working question regarding XSS testing.
2. Record the data sources and required evidence: context, encoding, CSP, stored/reflected/DOM.
3. Create a short Baseline of normal behavior or expected outcome.
4. Perform the minimal test in a lab environment and save time, input, and output.
5. Build a Timeline or comparison table and separate fact from interpretation.
6. Perform a Pivot to an additional source to confirm or refute the initial explanation.
7. Summarize a decision, limitations, recommended action, and Retest criteria.

Practical Scenario

The chosen scenario is mapping Input-to-Sink in a lab application. The purpose of the exercise is not to prove attack capability, but to practice safe collection, comparison, and documentation. Before starting, define simulated data, a time window, and an expected outcome.

At the end of the exercise, a deliverable that another analyst or tester can review should be submitted: a screenshot or export of the evidence, a short Timeline, an initial hypothesis, corroborating evidence, a limitation, and a recommendation. When there is insufficient evidence, the correct conclusion is that the scenario has not been proven.

Practical Checklist

• ✓Check and document: Role and session.
• ✓Check and document: Endpoint and method.
• ✓Check and document: Request/Response.
• ✓Check and document: Object identifier.
• ✓Check and document: Server-side effect.
• ✓Check and document: Control expected and remediation.
• ✓Specify Time zone, tool version, and collection time.
• ✓Save the raw data before filtering or modification.
• ✓Write what the finding proves and what is still unknown.
• ✓Define owner and next action with a due date.

Common Mistakes

• Only checking Status code.
• Relying on Client-side changes.
• Using a dangerous Payload.
• Not checking different Roles.
• Ignoring business logic.
• Reporting without clean Request/Response.

Professional Deep Dive: Quality, Context, and Control

Quality work on XSS testing is also measured by the ability to retrace the path to the conclusion. It is recommended to save Query, Filter, Scope, Timestamp, Dataset, and tool version. This allows for re-checking the same case after configuration changes or when additional information becomes available.

Business context changes the technical meaning. A critical asset, an account with elevated privileges, or an internet-facing service requires a different level of caution than an isolated lab. However, Criticality is not a substitute for evidence: it affects Priority and response actions, not whether the behavior actually occurred.

Peer review is an effective way to reduce errors. Another analyst should only receive the documentation and be able to understand the question, reproduce the search, and arrive at the same conclusion. If verbal explanations are required, the documentation is still incomplete.

Finally, every deliverable should become an opportunity for improvement: a missing log source, an unclear Playbook, a noisy Rule, broad permissions, or an inaccurate testing guideline. Documenting the action and Retest are what connect a one-time investigation to continuous improvement of the organization's capabilities.

Summary and CTA

Cross-Site Scripting: Stored, Reflected, and DOM is a topic that combines technical knowledge with work discipline. Start with a question, collect only relevant evidence, preserve context and time, and choose an action that can be justified and re-examined.

In HPI's Cybersecurity & AI track, these principles are practiced using systems, logs, and labs. A natural next step is to move on to the linked articles, complete the lab exercise, and save the deliverable as part of a professional portfolio.

FAQ