Delayed / auto-fire payload
Auto-fire top-redirect, postMessage, form submit, and similar actions after a timer or URL parameter.
Behavior by sandbox policy
| Policy | Expected result |
|---|---|
| No sandbox | works |
sandbox="allow-scripts" | partial |
sandbox="" (strictest) | blocked |
Embed snippet
This snippet uses the dedicated embed page. Paste it into your own service and check rendering or blocking behavior.
The current snippet has no sandbox restrictions. Use it to observe behavior, not as a production default.
<iframe src="https://xss-playground.com/embed/delayed-attack?lang=en" title="XSS Playground - Delayed / auto-fire payload" width="600" height="420" loading="lazy" referrerpolicy="strict-origin-when-cross-origin"></iframe>
Run
Action
Delay (seconds)
// no logs
Auto-fire embed page
For real embed testing, add URL parameters so the action runs without user interaction. Example:
<iframe src="https://xss-playground.com/embed/delayed-attack?auto=top-redirect&delay=5" width="600" height="420"></iframe>
Explanation
- Stored XSS and embedded attacks are often more dangerous when they run after the user has developed trust, not immediately at page load.
- Delayed execution is easy to miss in review. Test a few seconds later, after interaction, and on revisit instead of only checking the first render.
- Defenses are validated either by removing the payload at render time or by closing execution surfaces with CSP, sandbox, and message validation.