Web Security Payload Field Manual

The marker appears in HTML, an attribute, JavaScript, CSS, or a URL. Record which characters are encoded and where.

A dialog shows the current origin. If markup renders but the handler does not run, inspect CSP and sanitization.

Focus reaches the injected element and the handler runs. This payload is invalid for single-quoted or unquoted contexts.

The string terminates, the call executes, and the remaining source is commented. Escaping rules change for JSON and template literals.

The fragment is not sent to the server, so execution indicates a browser-side source-to-sink path.

A repeatable status, body, header, or timing change may indicate query parsing. A generic 500 alone is not proof.

Compare against the false control using the same request and stable application state.

A consistent content or behavior difference between true and false conditions is stronger evidence than either response alone.

An empty result or changed response compared with the original numeric value can reveal expression evaluation.

Use repeated baseline and delayed samples. Network jitter or slow application code can create false positives.

Correlate a unique token, timestamp, source address, DNS lookup, and HTTP request in your callback logs.

A callback from the first hop is expected; reaching a disallowed second destination indicates incomplete revalidation.

A response that differs from a controlled unreachable address may indicate internal access, but error handling can obscure results.

Compare with the IPv4 result and a negative control. The target service may not listen on IPv6.

This address should not identify a real Internet host. Fast rejection versus a timeout can reveal validation behavior, not SSRF by itself.

A literal echo is not vulnerable. Removal, substitution, or a template-specific error justifies engine-aware testing.

A rendered value of 49 suggests evaluation, but multiple engines share this syntax.

For example, Jinja2 commonly renders seven copies of 7 while Twig commonly renders 49. Version and configuration can differ.

A value of 49 indicates expression handling but does not identify the engine by itself.

A rendered value of 49 indicates evaluation in an ERB-like context.

The server must choose acceptable algorithms and key sources from configuration, not trust arbitrary header values.

Any authenticated response is a failure. A robust implementation rejects the token before authorization logic.

The token should be rejected with a consistent authentication error. Allow only a small documented clock-skew window.

The service should reject the token even when the signature is otherwise valid.

No callback should occur and the token should be rejected unless the URL is on a strict, intentional allowlist.

A unique fixture marker proves boundary escape without exposing sensitive files.

The same fixture appears only for the encoded request, indicating inconsistent normalization order.

The fixture appears after multiple decode passes. Confirm the exact component sequence before reporting.

The fixture appears when backslashes are interpreted as directory separators.

A controlled fixture outside the content root must remain inaccessible.

The marker appears in the response or captured process output.

The marker appears only when the original command returns success.

The marker appears even though pipeline behavior may replace or combine normal output.

The marker appears after a decoding layer converts %0a to a newline.

Repeated requests show a stable two-second delta over baseline. Use low concurrency and account for jitter.

The parsed value contains sc_xxe_7f3a. Internal expansion alone is not proof that external entities are enabled.

A correlated DNS or HTTP callback proves outbound resolution. The XML response need not include callback content.

A callback or included controlled marker indicates that XInclude is processed.

The rendered or transformed output contains the unique text marker.

A 3xx Location header or client-side navigation reaches the exact controlled URL.

The browser inherits the current scheme and navigates to the controlled host.

Browser and server parsing can differ. Confirm the final browser destination rather than relying only on string validation.

The actual host is your-controlled.example; trusted.example is the username component.

The final Location value or browser destination resolves to the controlled host.

A clean 4xx validation error is expected. Query-engine errors or changed results indicate unsafe type handling, not necessarily injection.

Compare with the same impossible value as a plain string. A behavior difference suggests operator interpretation.

Broader results or an authentication-state change indicates unsafe query construction. Stop after minimal proof.

Compare with username=sc-user-that-cannot-exist and inspect server-side parsing if available.

A difference from the equivalent plain string can reveal operator acceptance while preserving a no-match control.

Access-Control-Allow-Origin matching the untrusted origin is risky when sensitive data is available, especially with credentials.

Access-Control-Allow-Origin: null can expose data when attackers can generate a null origin.

The server must reject this unless the exact origin is intentionally trusted.

Acceptance may be intended only if trusted.example controls and secures every possible subdomain.

Review Access-Control-Allow-Origin, Access-Control-Allow-Credentials, allowed methods and headers, and Vary: Origin together.

Check browser console violations and verify that the final policy does not rely on unsafe-inline or broad wildcards.

Send HSTS only over HTTPS. Add includeSubDomains only after every subdomain supports HTTPS; preload has separate requirements and consequences.

Verify accurate Content-Type headers too; nosniff does not repair an incorrect media type.

Choose a stricter value if paths or query strings contain sensitive data.

Inventory real feature and iframe needs before rollout; unsupported directives are ignored by browsers.