You've secured your source repositories. Your API keys live in private repos, not public ones. Your CDN handles the edge logic. You're covered, right?
That's what Brevo thought before attackers used a hardcoded Cloudflare API key to compromise up to 100,000 websites in five and a half hours on September 14. The breach wasn't sophisticated; it exploited assumptions that many vendor due diligence teams still accept as fact.
These myths persist because they're partially true in specific contexts, but they fail catastrophically when attackers gain access through adjacent vectors. Here's what the Brevo incident reveals about API security assumptions that don't hold under real attack conditions.
Myth 1: Private repositories protect hardcoded credentials
Reality: Hardcoded credentials in source code create single points of failure regardless of repository access controls.
Brevo's compromised Cloudflare API key was hardcoded in application source code. Once extracted, whether through a supply chain compromise, insider access, or leaked commit history, that key granted full account permissions to create Workers, routes, and DNS records across all Brevo zones without triggering alerts.
Repository access controls protect against external discovery, but they don't mitigate credential exposure through developer workstations, CI/CD pipelines, container images, or third-party code analysis tools. When you're assessing a vendor's secrets management practices, ask specifically: Are API keys stored in dedicated vaults with rotation policies, or are they committed to version control? If they're in repos, even private ones, that's a finding.
Myth 2: Full-permission keys are fine if they're long-lived and monitored
Reality: Long-lived keys with full permissions maximize blast radius and detection lag.
The compromised Cloudflare key had full account permissions and was long-lived. Brevo confirmed the key may have been compromised as early as late August, though malicious activity wasn't detected until September 14. That's a potential exposure window of over two weeks before the five-and-a-half-hour active attack.
Least-privilege scoping limits what an attacker can do with a stolen key. Short-lived tokens reduce the window between compromise and expiration. When you're reviewing a vendor's API architecture, look for:
- Scoped tokens tied to specific resources or operations
- Rotation schedules measured in days or weeks, not months or years
- Separate keys for development, staging, and production environments
- Automated revocation triggers when keys are accessed from unexpected locations
Myth 3: CDN edge modifications will trigger standard integrity checks
Reality: Edge rewrites bypass origin-based integrity monitoring, and attackers know it.
Brevo's post-mortem is explicit: "Because the Worker rewrote responses at the edge and removed security headers such as Content-Security-Policy, our origin servers and files remained unmodified and standard integrity checks did not detect the change."
The malicious Cloudflare Worker modified content after it left Brevo's infrastructure but before it reached end users. Origin file hashes matched expected values. Subresource Integrity checks passed because the files at rest were clean. The attack surface was the CDN configuration layer, not the application layer most monitoring tools watch.
Your vendor questionnaires should ask: How do you monitor for unauthorized configuration changes at the CDN edge? What alerts fire when Workers, Lambda@Edge functions, or edge routing rules are created or modified? If the answer is "we monitor origin integrity," that's insufficient.
Myth 4: Removing Content-Security-Policy headers requires application-layer access
Reality: Attackers with CDN control can strip security headers at the edge, disabling browser protections without touching your application.
The malicious Worker removed Content-Security-Policy headers as responses passed through Cloudflare's edge. This disabled the browser's script execution controls, allowing the injected ClickFix scripts to run without CSP violations.
This matters for your due diligence process because it changes the threat model. A vendor can implement perfect CSP policies at the application layer, but if their CDN credentials are compromised, those policies disappear in transit. When you're assessing a vendor's defense-in-depth strategy, verify that security header enforcement happens at multiple layers, and that CDN configuration changes require multi-party approval or hardware token authentication.
Myth 5: Script injection attacks are detectable through customer-side monitoring
Reality: Edge-injected scripts appear legitimate to customer monitoring tools because they're served through trusted vendor domains.
The Brevo attack modified the Brevo forms script, Conversations widget, and SDK loader scripts that customers embedded on their sites. From the customer's perspective, these scripts were still served from brevo.com and sendinblue.com domains. Browser developer tools showed the expected origins. Subresource Integrity checks (if implemented) would have failed, but many sites don't use SRI for third-party marketing and CRM widgets.
For WordPress sites embedding Brevo widgets, the malicious script checked whether the visitor was logged in as an administrator and attempted to upload a backdoor plugin. The plugin hid itself from the WordPress plugin list, copied itself into the must-use plugins directory for persistence, and contained a hardcoded authentication key that allowed attackers to generate valid admin sessions without knowing passwords.
This is the Fourth and Nth Party Management materialized: your vendor's CDN compromise becomes your customer's WordPress compromise. When you're evaluating vendor security, ask: What compensating controls exist if your CDN is compromised? How would you notify customers if edge-served scripts are modified? What's the maximum detection lag between compromise and customer notification?
What to do instead
Stop accepting "we use private repos" as sufficient evidence of secrets management. Require vendors to demonstrate:
- Secrets stored in dedicated vaults (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) with audit logs
- API keys scoped to minimum necessary permissions, with documented justification for any full-access keys
- Automated rotation schedules with evidence of last rotation date
- Real-time alerting on CDN configuration changes, not just origin file modifications
- Subresource Integrity hashes published for all customer-embedded scripts
- Documented incident notification timelines that account for edge-layer compromises
For your own organization's embedded third-party scripts, implement Content-Security-Policy with strict script-src directives and require-sri-for where supported. Monitor for CSP violations in production; they're early indicators that something's rewriting responses in transit.
The Brevo incident proves that API security isn't a repository access control problem. It's a secrets lifecycle, least-privilege, and edge visibility problem. Adjust your vendor assessments accordingly.
