In March 2023, Apple quietly patched a surprising security flaw in macOS Ventura 13.3—one that had the potential to let unwanted scripts or resources leak through your browser’s security walls. This post takes you through CVE-2023-32370, a logic issue in how Content Security Policy (CSP) handled domain wildcards, why it was dangerous, how it was fixed, and what code behavior was at the heart of the risk.

What is CVE-2023-32370?

CVE-2023-32370 describes a logic issue in Apple’s WebKit (the engine behind Safari) which affected Content Security Policies. CSP is a browser feature that tells websites where they can (and can’t) load scripts, images, and data from—an essential defense against cross-site scripting (XSS) and data theft.
This vulnerability made it so that CSP domain blocking using wildcards (like *.evil.com) could fail—meaning blocked domains might not be blocked after all.

Apple’s Description

> A logic issue was addressed with improved validation. This issue is fixed in macOS Ventura 13.3. Content Security Policy to block domains with wildcards may fail.

*Source: Apple Security Updates*

Say your app wants to block any scripts from untrusted subdomains. You set a CSP rule like

Content-Security-Policy: script-src 'self' https://trusted.com *.trusted.com

Later, an attacker creates a crafty subdomain—maybe something like "trusted.com.evil.com"—and gets it referenced in your CSP. Due to the logic flaw, the browser might not properly block these crafted domains disguised as subdomains. That’s bad, because a wildcard that’s too loose can be exploited to sidestep what looked like a tight security net.

What Went Wrong?

The CSP check routine did not *strictly* validate wildcard matches. Here’s a basic look at what *should* happen:

function isAllowed(domain, allowedList) {
    for (const allowed of allowedList) {
        if (allowed.startsWith('*.')) {
            // Only allow subdomains (e.g., one layer under base domain)
            let base = allowed.slice(2); // e.g., "trusted.com"
            if (domain.endsWith('.' + base)) {
                return true;
            }
        } else if (domain === allowed) {
            return true;
        }
    }
    return false;
}

But if the original WebKit code wasn’t strict enough, it might just check if the domain *contains* the substring, not a full subdomain match:

if (domain.includes(allowedWithoutWildcard)) {
    // Oops! "trusted.com.evil.com" would match "*.trusted.com"
    return true;
}

That’s a problem because trusted.com.evil.com isn’t a real subdomain of trusted.com, but a separate domain entirely.

Try this in a test

<meta http-equiv="Content-Security-Policy" content="script-src 'self' *.trusted.com">
<script src="https://trusted.com.evil.com/malware.js"></script>

The Fix

Apple patched this by adding “improved validation” to make sure wildcards could only match real subdomains—not tricky lookalikes. This was rolled out with Ventura 13.3 and Safari updates.

You can see the public disclosure on the Apple Security Updates page for Ventura 13.3.

Final Thoughts

CVE-2023-32370 is a lesson in how even small logic errors can undermine the whole idea behind browser security policies. If you maintain web apps or set CSPs, always double-check your wildcard usage and keep clients up to date.

References and Further Reading

- Apple Security Updates - macOS Ventura 13.3
- Content Security Policy (MDN)
- CVE-2023-32370 details (NVD)

Timeline

Published on: 09/06/2023 02:15:00 UTC
Last modified on: 09/11/2023 18:15:00 UTC