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.
<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.