Guías HTML para sandbox

The sandbox attribute applies a strict set of restrictions to content loaded inside an <iframe>. By default, sandboxed iframes cannot run scripts, submit forms, open popups, or access storage. You can selectively lift specific restrictions by adding recognized keywords like allow-scripts, allow-forms, allow-popups, allow-same-origin, and others defined in the WHATWG HTML standard.

The keyword allow-storage-access-by-user-activation was proposed as a way to let sandboxed iframes request access to first-party storage (such as cookies) after a user gesture. However, this keyword was never adopted into the HTML specification. The functionality it aimed to provide is now handled by the Storage Access API, which uses document.requestStorageAccess() and document.hasStorageAccess() in JavaScript. Because the keyword was never standardized, the W3C validator correctly flags it as invalid.

Why this matters

• Standards compliance: Using non-standard keywords means your HTML doesn’t conform to the specification, which the validator will flag as an error.
• Browser inconsistency: Since this keyword was experimental and never standardized, browser support is unreliable. Some browsers may silently ignore it, while others may have briefly supported it before removing it.
• False sense of security: Including an unrecognized sandbox keyword doesn’t actually enable the behavior you expect. The iframe won’t gain storage access just because this keyword is present—the browser simply ignores unknown tokens.

How to fix it

1. Remove the invalid keyword from the sandbox attribute.
2. Keep any other valid sandbox keywords that your iframe needs.
3. Use the Storage Access API in JavaScript within the iframe if you need cross-site storage access. The embedded page must call document.requestStorageAccess() in response to a user gesture, and the sandbox attribute must include allow-scripts and allow-same-origin for this API to work.

Examples

❌ Invalid: using a non-standard sandbox keyword

<iframe
  src="https://example.com/widget"
  sandbox="allow-scripts allow-same-origin allow-storage-access-by-user-activation">
</iframe>

✅ Valid: removing the non-standard keyword

<iframe
  src="https://example.com/widget"
  sandbox="allow-scripts allow-same-origin">
</iframe>

The embedded page at https://example.com/widget can then use the Storage Access API in JavaScript:

document.querySelector('#login-button').addEventListener('click', async () => {
  const hasAccess = await document.hasStorageAccess();
  if (!hasAccess) {
    await document.requestStorageAccess();
  }
  // Storage (cookies, etc.) is now accessible
});

✅ Valid: sandbox with other standard keywords

If your iframe doesn’t need storage access at all, simply use the standard keywords you require:

<iframe
  src="https://example.com/form"
  sandbox="allow-scripts allow-forms allow-popups">
</iframe>

Note that for document.requestStorageAccess() to work inside a sandboxed iframe, you must include both allow-scripts (so JavaScript can run) and allow-same-origin (so the iframe retains its origin). Without these, the Storage Access API calls will fail.

The sandbox attribute is one of the most powerful security features available for <iframe> elements. When present with no value (or with specific tokens), it applies a strict set of restrictions to the embedded content — blocking scripts, form submissions, popups, same-origin access, and more. You selectively relax these restrictions by adding space-separated tokens like allow-scripts, allow-forms, or allow-popups.

The problem arises specifically when allow-scripts and allow-same-origin are used together. The allow-scripts token lets the embedded page execute JavaScript, while allow-same-origin lets it retain its original origin (rather than being treated as coming from a unique, opaque origin). With both enabled, the embedded page’s JavaScript can access the parent page’s DOM via window.parent (if they share the same origin) or, more critically, can use JavaScript to programmatically remove the sandbox attribute from its own <iframe> element. Once the attribute is removed, all sandboxing restrictions are lifted, making the sandbox attribute completely pointless.

This is why the W3C validator flags this combination — it’s not technically invalid HTML, but it’s a security anti-pattern that renders sandboxing ineffective. The WHATWG HTML specification explicitly warns against this combination for the same reason.

How to fix it

The fix depends on what the embedded content actually needs:

1. If the embedded page needs scripts but not same-origin access: Remove allow-same-origin. The page can still run JavaScript but will be treated as a unique origin, preventing it from accessing cookies, storage, or the parent frame’s DOM.

2. If the embedded page needs same-origin access but not scripts: Remove allow-scripts. The page retains its origin but cannot execute any JavaScript.

3. If you believe both are required: Reconsider whether sandboxing is the right approach. If the embedded content truly needs both script execution and same-origin access, the sandbox attribute provides no meaningful security benefit, and you may want to use other security mechanisms like Content-Security-Policy headers instead.

Always follow the principle of least privilege — only grant the permissions the embedded content strictly requires.

Examples

❌ Bad: using both allow-scripts and allow-same-origin

<iframe
  src="https://example.com/widget"
  sandbox="allow-scripts allow-same-origin">
</iframe>

This triggers the validator warning because the embedded page can use its script access combined with its preserved origin to break out of the sandbox entirely.

❌ Bad: both flags present alongside other tokens

<iframe
  src="https://example.com/widget"
  sandbox="allow-forms allow-scripts allow-same-origin allow-popups">
</iframe>

Even with additional tokens, the presence of both allow-scripts and allow-same-origin still defeats the sandbox.

✅ Good: allowing scripts without same-origin access

<iframe
  src="https://example.com/widget"
  sandbox="allow-scripts">
</iframe>

The embedded page can run JavaScript but is treated as a unique opaque origin, preventing it from accessing parent-page resources or removing its own sandbox.

✅ Good: allowing only the necessary permissions

<iframe
  src="https://example.com/widget"
  sandbox="allow-scripts allow-forms allow-popups">
</iframe>

This grants script execution, form submission, and popup capabilities while keeping the content sandboxed in a unique origin.

✅ Good: using an empty sandbox for maximum restriction

<iframe
  src="https://example.com/widget"
  sandbox="">
</iframe>

An empty sandbox attribute applies all restrictions — no scripts, no form submissions, no popups, no same-origin access, and more. This is the most secure option when the embedded content is purely static.

✅ Good: removing the sandbox when it provides no real benefit

<iframe
  src="https://example.com/widget"
  title="Example widget">
</iframe>

If you genuinely need both script execution and same-origin access, it’s more honest to omit sandbox entirely and rely on other security measures, rather than including an attribute that provides a false sense of security.