Section 29: HTML Security and Safe Embedding

Learning Objectives

• Understand common HTML-related security risks.
• Use iframe sandboxing appropriately.
• Understand safe link attributes and untrusted content.
• Learn why server-side security remains essential.

1. HTML Alone Cannot Secure an Application

HTML describes page structure and controls. Application security also depends on server-side authorization, validation, secure session handling, output encoding, HTTPS and correct configuration.

2. Cross-Site Scripting (XSS)

Cross-site scripting can occur when untrusted input is inserted into a page in a way that allows executable script or unsafe markup to run.

<!-- Do not paste untrusted user input into HTML as trusted markup -->
<div id="comment"></div>

<script>
  const comment = document.querySelector("#comment");
  const userText = "<img src=x onerror=alert('example')>";

  // Treat the value as text, not executable HTML.
  comment.textContent = userText;
</script>

textContent treats the string as text. When an application must render user-authored rich HTML, use a suitable, maintained HTML sanitizer and a carefully designed security policy.

3. Safe Link Practices

<a href="https://example.com"
   target="_blank"
   rel="noopener noreferrer">
  Open external website
</a>

noopener prevents the opened page from accessing the opener window through window.opener. Modern browsers generally apply noopener behavior to target="_blank" links by default, but writing it explicitly can make the intention clear. noreferrer also suppresses the Referer header and implies noopener.

4. Iframe Sandbox

An iframe embeds another browsing context. The sandbox attribute restricts capabilities unless particular permissions are granted.

<iframe
  src="https://example.com/widget"
  title="Example widget"
  sandbox
  loading="lazy"
  width="600"
  height="400">
</iframe>

An empty sandbox applies a strong set of restrictions. Embedded content may not function until the required permissions are explicitly allowed. Add only permissions that are genuinely necessary.

5. Be Careful with Sandbox Permissions

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

allow-scripts permits scripts inside the embedded page. Permissions such as allow-same-origin can change the security properties significantly. Avoid combining allow-scripts and allow-same-origin for untrusted same-origin content without a careful security review.

6. URL and Form Security

• Use HTTPS for pages that transmit sensitive information.
• Validate submitted values on the server.
• Restrict redirect destinations to trusted URLs where applicable.
• Use authorization checks for protected resources.
• Protect state-changing requests against CSRF where applicable.
• Do not trust hidden inputs or disabled controls as security controls.

7. HTML Escaping

When inserting untrusted content into HTML text, special characters such as the less-than sign must be handled safely. Context matters: HTML text, attributes, URLs, CSS and JavaScript have different encoding requirements.

<p>User-entered text should be rendered as text, not interpreted as markup.</p>

Use framework-provided escaping facilities where available. Avoid building HTML strings with untrusted input and assuming that a single generic escaping function is safe for every context.

Common Mistakes

• Assuming HTML validation prevents malicious requests.
• Inserting untrusted content with unsafe HTML rendering.
• Giving embedded content more sandbox permissions than necessary.
• Trusting hidden form fields for authorization or pricing.
• Assuming target="_blank" alone is a complete security strategy.

Practice Exercises

1. Create an external link with target="_blank" and explicit rel attributes.
2. Build a sandboxed iframe and explain its restrictions.
3. Explain why textContent is safer than interpreting untrusted input as HTML.
4. List three server-side protections that an HTML form cannot provide by itself.

Revision Quiz

1. What is XSS?
2. What does noopener prevent?
3. What does iframe sandbox do?
4. Should untrusted user input be rendered as executable HTML?
5. Are hidden inputs trustworthy for access control?
6. Can HTML validation replace server-side validation?

Answer Key and Explanations

1. Cross-site scripting — It involves unsafe content being interpreted as executable script or markup.
2. Access through window.opener — It helps isolate a newly opened browsing context from its opener.
3. Restricts embedded content capabilities — Permissions can be granted selectively.
4. No. Render untrusted input as text or sanitize rich HTML with an appropriate sanitizer.
5. No. Users can inspect and change client-submitted values.
6. No. The server must validate and authorize requests independently.