Blog

A simple does more than open a new tab. It sends the browser's document.referrer to the target site and gives it partial control via window.opener. These two defaults — referrer leakage and tab-napping — are among the most overlooked privacy risks in everyday HTML. A malicious site could redirect your original tab to a phishing page while you're distracted. The fix starts with the rel attribute.

Link Privacy: rel="noopener" and rel="noreferrer"

Every external link with target="_blank" should be accompanied by rel="noopener". Without it, the newly opened page can access window.opener and redirect the original tab to a phishing site (a technique called tab-napping). The fix is simple:

<a href="; target="_blank" rel="noopener">Visit Example</a>

Adding rel="noreferrer" goes a step further: it prevents the Referer header from being sent and also implies noopener. Use it when you want to hide the referring page altogether:

<a href="; target="_blank" rel="noreferrer">Visit Example (anonymous referrer)</a>

Modern browsers default to noopener behavior for target="_blank" links, but relying on that is risky — older browsers and some custom user agents still expose the referrer and opener.

Controlling the Referrer Header

Beyond individual links, the Referrer-Policy HTTP header gives site-wide control over how much information is shared with external destinations. The most privacy-friendly value is no-referrer, which omits the header entirely. A more balanced choice is strict-origin-when-cross-origin — it sends the origin (scheme + host) only when navigating from HTTPS to HTTPS, and nothing when going to a less secure target.

You can set this policy in your server configuration or via a <meta> tag:

<meta name="referrer" content="strict-origin-when-cross-origin">

For pages that embed external resources (images, scripts, fonts), the referrer policy also applies to subresource requests. If your site includes analytics pixels or third-party widgets, consider setting no-referrer-when-downgrade as a reasonable baseline to prevent HTTPS pages from leaking the full URL to HTTP endpoints.

Third-Party Embeds and sandbox

Embedding YouTube videos, Twitter timelines, or advertising iframes exposes your visitors to third-party tracking scripts. HTML5's sandbox attribute on the <iframe> element restricts what the embedded content can do. A strict sandbox with only the permissions you need:

<iframe src="; sandbox="allow-scripts allow-same-origin"></iframe>

This configuration allows JavaScript execution (needed for many embeds) but disables pop-ups, form submission, and access to the parent's localStorage via allow-same-origin. Be careful: allow-scripts combined with allow-same-origin lets the iframe run arbitrary code that can interact with the embedding origin — that may defeat some privacy protections. For most privacy-oriented use cases, omit allow-same-origin and only enable allow-scripts if essential.

Cookies and SameSite

HTML alone cannot set cookie policies, but it interacts with them through cross-site requests. The SameSite cookie attribute (Lax, Strict, None) controls when cookies are sent in cross-site contexts. If your site includes third-party embeds that set cookies, those cookies are blocked by default in modern browsers when SameSite=None; Secure is not explicitly set. Developers should audit all cookies created by embedded content and set an appropriate SameSite policy server-side.

Local Storage, Session Storage, and Cache

HTML5 introduced localStorage and sessionStorage, giving web applications persistent client-side storage. Unlike cookies, these are not automatically sent with every HTTP request, but they are accessible to any JavaScript running on the same origin. If your page loads third-party scripts (analytics, ads, heatmaps), those scripts can read and write to localStorage — potentially fingerprinting users or exfiltrating data. Mitigate this by:

• Loading third-party scripts from a separate subdomain (e.g., static.example.com) so they cannot access the main domain's storage.
• Using Subresource Integrity (SRI) hashes in <script> tags to ensure the loaded script has not been tampered with.
• Reviewing each embedded script for its storage usage — tools like the browser's Application panel can list all keys.

The browser cache also stores HTML pages, CSS, and images. If sensitive data appears in cached files, an attacker with physical access or a compromised browser profile could retrieve it. Adding the Cache-Control: no-store response header for sensitive pages prevents caching entirely. For static assets that do not contain personal information, a longer cache lifetime improves performance without privacy risk.

Content Security Policy (CSP) for Privacy

Content Security Policy is primarily a security mechanism, but it also reduces privacy leakage by restricting which origins can load resources. For example, if your site never intends to load scripts from doubleclick.net, a CSP directive script-src 'self' blocks any attempt to inject a tracking script via XSS or compromised third-party code.

A privacy-focused CSP might look like:

Content-Security-Policy: default-src 'self'; img-src 'self' ; connect-src 'self'; script-src 'self' 'nonce-abc123'; frame-src 'none';

The frame-src 'none' directive prevents any iframe from being embedded on your page — useful if you do not use third-party widgets. The connect-src 'self' limits XHR and fetch requests to your own origin, blocking beacon-based tracking.

Practical Steps for a Privacy-First HTML Page

Combine the techniques above into a checklist for new pages or audits:

1. Add rel="noopener noreferrer" to every external link with target="_blank".
2. Set a Referrer-Policy header, preferably strict-origin-when-cross-origin or no-referrer.
3. Sandbox all third-party iframes; start with sandbox="" (empty, all restrictions) and add permissions one by one.
4. Review all third-party scripts and replace heavy iframes with lightweight, self-hosted alternatives where possible.
5. Use CSP headers to block unauthorized resource loads and prevent framing.
6. Serve all pages over HTTPS to prevent network-level leaking of referrers and cookies.

Start with the first two items — rel="noopener noreferrer" and a Referrer-Policy header — and you'll cut out the most common leaks. Then tighten the rest with sandbox, CSP, and SameSite. Your users won't notice the difference, but their data will be safer.