🔐 VAPT Checklist for iframe & postMessage Communication ✅ IFRAME Security Considerations
Check
Description
X-Frame-Options header Should be set to DENY or SAMEORIGIN to prevent Clickjacking.
Content-Security-Policy (CSP) Use frame-ancestors, child-src, frame-src directives to restrict embedding origins.
Sandboxing iframes Use sandbox attribute with strict flags like allow-scripts or allow-forms.
Avoid unnecessary iframe permissions E.g., allowfullscreen, allowpopups can increase risk if not required.
Cross-origin iframe checks If external domains are embedded, test for XSS or insecure handling in the iframe content.
Form input behavior in iframe Ensure the embedded content cannot be used for phishing, form jacking, or injection.
✅ postMessage Security Considerations
Check
Description
Always validate event.origin Critical: don’t trust messages from * or unknown domains.
Strict allowlist of origins Compare event.origin against known safe domains.
Validate structure of event.data Use strict schema validation; avoid trusting arbitrary keys or values.
Avoid sensitive actions triggered directly Don’t delete users, perform redirects, or auth actions based on messages alone.
No sensitive data in postMessage Tokens, internal state, or user data should not be passed without encryption + auth.
Always use targetOrigin in sender Avoid postMessage(..., "*") unless you're sure there's no sensitive data.
🧪 Combined Scenario Vulnerabilities
Scenario
Risk
Trusted parent → untrusted iframe + insecure postMessage Privilege escalation, message forgery
Untrusted parent → trusted iframe Clickjacking, phishing
PostMessage triggers logic without auth Business logic abuse, account manipulation
No CSP + no XFO + iframe + messages Complete UI spoofing, full-frame phishing
🛡️ Recommended Mitigations
Area
Recommendation
Framing protection Use X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors 'none'
Sandbox iframes E.g., <iframe sandbox="allow-scripts"> unless more permissions are explicitly needed
Message validation On receiving messages: check event.origin, event.source, and event.data content
Safe sender Always use explicit targetOrigin, avoid using "*"
Auth checks All business-critical logic should be behind session/auth validation, not just message triggers
💥 PoC: Cross-Origin postMessage Spoofing This code simulates an attacker page trying to send a forged message to a target app that listens to postMessage.
<!DOCTYPE html>
< html >
< head >
< title > PoC: Cross-origin Message Spoofing</ title >
</ head >
< body >
< h2 > Sending forged postMessage...</ h2 >
< script >
// Target origin: victim site
const targetOrigin = "https://victim-app.example.com" ;
// Open the target in an iframe (or window)
const win = window . open ( targetOrigin ) ;
// Wait briefly before sending message
setTimeout ( ( ) => {
win . postMessage (
{
action : "deleteUser" ,
user : "admin"
} ,
"*"
) ;
} , 3000 ) ;
</ script >
</ body >
</ html >
Monitor browser postMessage events using DevTools console (message event listener).
Inject forged postMessage events and see if the app reacts without validating origin or structure.
Review JS source for window.addEventListener("message", handler) and locate handler logic.
📄 Reporting Title Samples
Client-Side Security | Missing origin validation in postMessage receiverClickjacking | Absence of X-Frame-Options allows sensitive UI to be framed
🛑 Additional iframe Security Issues
Occurs when a malicious site embeds the target app in an invisible iframe and tricks users into clicking buttons.
Mitigation : Use X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors 'none'.
2. Phishing or UI Redress Attacks
Third-party iframes may overlay or mimic legitimate UI components.
Mitigation : Use sandbox with minimal permissions and CSS controls to block pointer events.
3. Data Leakage via Referrer Headers
Embedding secure content in iframes may leak tokens in URLs via the Referer header.
Mitigation : Use Referrer-Policy: no-referrer or avoid embedding sensitive resources.
4. Untrusted Iframe Message Spoofing
Untrusted iframes can spoof postMessage events and receive sensitive responses.
Mitigation : Always validate event.origin and event.source.
5. Third-party iframe JavaScript Injection
If third-party iframe content is under partial control (e.g., Markdown rendering), it can inject JS to escape sandbox.
Mitigation : Use strong CSP, HTML sanitization, and sandbox without allow-scripts.
✅ iframe-Specific Security Checklist
Area
Best Practice
Clickjacking protection
X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors
Third-party iframes
Use <iframe sandbox> with least privileges
Data privacy
Avoid passing tokens or user data to embedded iframes unless scoped + validated
Message integrity
Always verify postMessage sender origin and structure
Referrer control
Use Referrer-Policy: no-referrer to avoid token leakage
JS isolation
Avoid allow-scripts unless strictly needed, and pair with CSP
