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 dialog or console proof tied to the SVG sink confirms execution. CSP may still block handlers.

Expression evaluation indicates a template-literal sink. Escape rules differ from quoted strings.

Execution or a framework-specific error justifies deeper client-template testing. Prefer framework docs for current versions.

Navigation executes script in the page origin. Many browsers restrict javascript: in some contexts.

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.

A changed result set or syntax error about column count guides the next controlled UNION step. Escalate only with explicit scope.

Compare against ORDER BY 1 and an out-of-range index. Stable differences suggest expression evaluation.

Repeated baseline versus delayed samples should show a stable delta. Account for connection pooling jitter.

Seeing the marker or a multi-statement error is informative. Do not run destructive stacked statements.

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 response consistent with loopback access indicates weak IP literal validation.

Any local file content or scheme-specific error outside HTTP policy is a finding. Prefer fixtures when available.

Metadata body or distinctive headers prove cloud SSRF impact. Stop after minimal proof and do not harvest secrets.

Correlate DNS answers with later connections. A second resolve to a private address after an allowlisted first answer is the signal.

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.

Rendered 49 supports evaluation. Do not jump to Execute or object introspection.

A rendered 49 or template parse error specific to Thymeleaf justifies engine-aware follow-up.

Evaluation or a sandbox error is enough. Prefer non-RCE proofs in reports.

Rendered 49 indicates evaluation. Confirm engine via error messages before any further probe.

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.

Acceptance of a forged HMAC token signed with the published public key is a critical failure. Use only test accounts.

Unexpected acceptance or path traversal into a default key file indicates unsafe kid handling.

The service should reject the token even when the signature would otherwise verify against an unrelated key set.

No authentication success should occur when the header carries an untrusted jwk. Callbacks are not expected.

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.

Fixture content with a trailing encoded null suggests truncation. Modern runtimes often reject this.

Fixture content after nested dots indicates incomplete sanitization.

Unexpected share access or distinctive errors indicate UNC interpretation. Prefer local fixtures.

Fixture marker text in the response proves local file inclusion without touching system secrets.

Command output or wrapper-specific errors indicate expect:// availability. Prefer php://filter for read-only proofs when needed.

Base64 of the fixture marker in the response proves wrapper-assisted LFI.

Callback plus included marker content proves RFI. Do not host executable shells.

Fixture content despite a forced suffix indicates null-byte truncation.

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.

Marker output indicates backtick evaluation inside a shell.

Marker output indicates $(...) evaluation. Prefer printf markers over file or network commands.

Marker appears in process output. Do not use destructive commands.

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 correlated callback proves outbound DTD fetching even if the document body stays empty.

Hardened services return a clear rejection. Silent acceptance of DOCTYPE warrants deeper XXE tests.

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.

Browser navigation into a data: document can enable phishing. Confirm the final client destination.

Final navigation to your-controlled.example is the signal. Server and browser parsers may disagree.

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.

Unexpected authentication or enumeration versus an empty-string baseline indicates operator reach.

Acceptance or engine errors around $where are enough. Do not run expensive or looping expressions.

A schema payload in the response expands the attack surface. Many programs still allow it in staging only.

Did-you-mean hints or stack traces disclose schema details useful for further testing.

Both operations execute in one HTTP request. Combine with authz tests carefully and keep concurrency low.

Many aliased fields succeed where depth limits alone are insufficient. Watch CPU and resolver timing.

Email or private fields for User:2 without entitlement is broken object authorization, not injection.

Use this as the control when comparing against deeper nested queries for complexity limits.

If the server stores or serves the file as executable PHP, the allowlist is unsafe. Prefer non-exec proof when possible.

Acceptance without content sniffing indicates weak validation. Stored XSS or parse errors are secondary signals.

Script execution when the SVG is opened in-browser proves stored XSS via upload. Prefer console markers over alerts in shared apps.

File appears outside the upload directory or overwrite occurs. Use unique fixture names only.

Stored name becomes .php or validation bypasses the image suffix. Modern stacks often reject nulls.

After the request, ({}).scPolluted === 'sc_proto_7f3a' in the same app context proves pollution.

The same polluted property on a fresh object is the signal.

Server behavior changes for unrelated objects or explicit debug output of polluted keys confirm the issue.

A page script reading ({}).scPolluted after hash parsing proves client-side pollution.

Pollution still appears on Object.prototype when nested keys are merged unsafely.

Directory errors, empty results, or authentication anomalies versus a plain string baseline are signals.

Broader results or unexpected auth success on a test account indicates filter injection. Stop at minimal proof.

Enumerating many entries with a single star suggests missing allowlists. Limit result size in tests.

Safe APIs treat the escaped form as literal data. Behavioral gaps versus raw * help confirm injection.

Unexpected mail attributes in results show filter logic compromise. Use synthetic directory data when possible.

A successful change proves missing server-side token validation. Use a disposable test account.

Acceptance of another account's token indicates weak binding.

State change from a cross-origin form-like request proves CSRF on an API that assumed JSON was safe.

SameSite=None cookies require strong CSRF tokens. Lax/Strict reduce but do not replace token checks for all cases.

State change through an unexpected verb path indicates middleware gaps.

Invoice fields for 1002 in the response prove missing object-level authorization.

Successful update or read indicates the server trusted the client ownership field.

Access to 1002 after decoding shows obscurity without authorization.

Export data or 200 instead of 403 indicates broken function-level authorization.

Resource payload from tenant B is a tenancy isolation failure.

Server errors mentioning ObjectInputStream or acceptance of rO0AB blobs justify deeper review. Do not send gadget chains.

Application logic reflecting sc_deser_7f3a or unserialize errors confirms the sink. Avoid POP chains.

Any server acceptance of pickle bytes from clients is high risk. Prefer replacing pickle with JSON.

Unexpected type loading errors or honor of $type without allowlists is the signal. Do not load gadget types.

Constructed objects or loader errors about python/object tags prove unsafe YAML loading. Use safe_load equivalents.

A reflected X-SC-Injected response header containing the marker proves splitting or header injection.

An unexpected Set-Cookie for sc_crlf indicates response splitting. Use only disposable test browsers.

A forged log line containing the marker appears beside the real event. Avoid flooding production logs.

Extra response headers after Location prove splitting. Confirm with a raw HTTP client.

HTTP/2 rejects raw newlines in many stacks. A failure on h2 with success on h1 still matters behind misconfigured downgrades.

If the app authorizes as admin while logs show user, parsing is inconsistent across layers.

Unexpected type coercion or the ignored value becoming authoritative is the signal.

Security checks reading one source while business logic reads the other enable bypasses.

Differential behavior between WAF and app parsers can hide or create access bugs.

If either value can override identity checks, document which component trusted which source.

Timeouts, unexpected 400 classes, or desync symptoms justify specialist follow-up. Do not poison shared frontends casually.

Desync indicators differ by proxy. Prefer PortSwigger lab methodology over production spray.

Different treatment by edge versus origin is the classic desync prerequisite.

Architecture notes plus a controlled lab proof are enough for many reports. Avoid live poisoning.

Without a baseline, timeouts are not evidence. Keep concurrency at one during desync research.

If the response contains private account HTML and later loads without cookies, the cache keyed on the static suffix.

Cached private content under a delimiter variant is the finding. Compare with a logged-out fetch.

Private body cached under the encoded path indicates normalization bugs.

Missing no-store on authenticated HTML is a configuration finding even before deception succeeds.

Poisoned Location or absolute URLs served to later victims indicate web cache poisoning. Use unique cache busters.

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.

Browsers reject this pairing, but seeing it in raw headers indicates a broken CORS configuration worth fixing.

Allowing PUT, DELETE, or uncommon methods for untrusted origins expands impact when ACAO is loose.

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.

The page should refuse framing by unexpected origins. Verify with a controlled iframe test page.

Popup and postMessage flows may break; stage carefully and confirm intended cross-window behavior.