This test page demonstrates a security vulnerability where a cross-origin iframe has a weak or missing referrer policy, potentially leaking sensitive information through the HTTP Referer header.
Test Case
<iframe
src="https://example.com/iframe-content.html"
crossorigin="anonymous"
width="100%"
height="300"
></iframe>Notice the absence of a referrerpolicy attribute, which means the default policy will be used.
Note: This is simulating a cross-origin iframe for testing purposes
Explanation
When a webpage includes an iframe, the browser sends a Referer HTTP header to the embedded content's server, containing the URL of the parent page. Without a proper referrer policy, this can lead to privacy and security issues:
- URL parameters might contain sensitive data (session tokens, user IDs, etc.)
- Path information could reveal restricted content or site structure
- Origin information could be used for targeted attacks
- Referrer data can be used for cross-site tracking
- Information leakage across HTTP/HTTPS boundaries
The default referrer policy in most browsers (no-referrer-when-downgrade) still sends significant information, especially when navigating between HTTPS resources.
How Pink Sock detects this issue:
Pink Sock analyzes iframe elements with cross-origin src attributes and checks for the presence of a secure referrerpolicy attribute. When iframes load cross-origin content without a strict referrer policy, it flags it as a low-severity security issue.
How to fix:
Add a strict referrerpolicy attribute to cross-origin iframes:
<iframe
src="https://example.com/iframe-content.html"
crossorigin="anonymous"
referrerpolicy="no-referrer"
width="100%"
height="300"
></iframe>For maximum security, use no-referrer to completely prevent the Referer header from being sent. Other secure options include same-origin (only send referrer information for same-origin requests) or strict-origin (send only the origin for cross-origin requests, and only if the security level stays the same).
Additional Information
Referrer Policy Options
The referrerpolicy attribute accepts the following values, listed from most to least secure:
| Value | Description | Security Level |
|---|---|---|
| no-referrer | No Referer header is sent | Highest |
| same-origin | Sends full URL for same-origin, nothing for cross-origin | High |
| strict-origin | Sends only origin for cross-origin, and only if security level stays the same | High |
| strict-origin-when-cross-origin | Sends full URL for same-origin, only origin for cross-origin, and only if security level stays the same | Medium |
| origin | Sends only the origin part of the URL, regardless of same or cross-origin | Medium |
| origin-when-cross-origin | Sends full URL for same-origin, only origin for cross-origin | Medium |
| no-referrer-when-downgrade (default) | Sends full URL unless going from HTTPS to HTTP | Low |
| unsafe-url | Always sends full URL, even for cross-origin and HTTPS-to-HTTP | Lowest |
Page-Level Referrer Policy
In addition to iframe-specific policies, you can set a site-wide referrer policy via meta tags or HTTP headers:
<meta name="referrer" content="no-referrer">Or via HTTP header:
Referrer-Policy: no-referrerReal-World Risk Scenario
Consider a password reset page with a URL like:
https://your-site.com/reset-password?token=a1b2c3d4e5f6g7h8i9j0If this page embeds a third-party iframe (like an analytics script or ad) without a proper referrer policy, the reset token could be leaked to the third party, potentially allowing account takeover.
Broader Protection Strategy
A proper referrer policy should be combined with other security measures:
- Avoid placing sensitive information in URLs
- Implement proper Content Security Policy (CSP)
- Use POST requests instead of GET for sensitive operations
- Implement short-lived tokens for sensitive operations
- Consider Cross-Origin Resource Policy (CORP) for additional protection