HTML Security & Embedding

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.