The Capital One breach in 2019 exposed the records of over 100 million customers. The cause wasn't a zero-day exploit or a nation-state attack. It was a misconfigured web application firewall and an overly permissive IAM role.
The Twitch source code leak in 2021 — again, not a sophisticated attack. Misconfigured internal access controls.
The 2022 Toyota supplier breach exposed 296,019 customers' data. The cause: an access key inadvertently published in a public GitHub repository.
The pattern is consistent: the biggest, most damaging breaches often start not with brilliance, but with a setting someone forgot to check.
Case Study: The Subdomain Takeover Chain
Here's a realistic attack chain starting with a single misconfigured DNS record:
Step 1 — The abandoned subdomain
A development team spins up dev.yourcompany.com and points it at a Heroku dyno for a project. The project gets cancelled six months later. The team decommissions the Heroku app but forgets to remove the CNAME record in DNS.
Now dev.yourcompany.com points to a hostname on Heroku's infrastructure that no longer exists. Heroku will happily let anyone create a new app at that hostname.
Step 2 — Discovery
An attacker (or automated tool) queries certificate transparency logs for yourcompany.com. They find dev.yourcompany.com listed. They resolve it and receive Heroku's generic "no such app" page. They recognise this as a subdomain takeover candidate.
Step 3 — Claiming the subdomain
The attacker creates a free Heroku account and creates an app with the matching hostname. Within seconds, dev.yourcompany.com is serving the attacker's content under your domain.
Step 4 — Exploitation
Now the attacker can:
- Run phishing pages — "dev.yourcompany.com/login" is a genuine yourcompany.com URL. Email security tools will not flag it as suspicious.
- Steal session cookies — because the subdomain is *.yourcompany.com, cookies set on your main domain with a wildcard scope may be readable by the attacker's page.
- Bypass email security — some SPF configurations allow dev.yourcompany.com to send email, meaning the attacker can send email "from" your domain.
Case Study: The CORS Misconfiguration
A startup builds an API at api.yourcompany.com. During development, they set the CORS policy to Access-Control-Allow-Origin: * to avoid cross-origin errors while testing.
The API goes to production. The CORS header stays. Nobody notices because the API "works".
What this enables
Any website — including a malicious one — can make API requests to api.yourcompany.com in the context of a logged-in user's session.
An attacker creates a malicious page and sends it to a user via a phishing email. When the victim visits the page while logged into your application, the malicious page silently calls your API on their behalf. It can:
- Read all their private data
- Modify their account settings
- Export their order history
- Change their email or password
The user sees nothing. The attacker gets everything.
The fix: Set a specific, explicit Access-Control-Allow-Origin header that names only your own domain. This takes thirty seconds to change.
Case Study: The Public S3 Bucket
A marketing agency uploads project assets to an Amazon S3 bucket for a client campaign. The bucket is set to public for convenience — "it's just marketing images".
Three months later, a developer uses the same bucket to store a backup of the client's customer database. They follow the same pattern as everything else in the bucket — public access. "It's just a backup."
What attackers find
Automated tools continuously scan for publicly accessible S3 buckets. They find yours within hours of the backup being uploaded. Your customer database — names, email addresses, order history, partially masked payment details — is downloaded.
You don't know. There are no access logs configured on the bucket. The first sign is a notification from a researcher who found your data on a dark web forum six weeks later.
The fix: All S3 buckets containing anything other than intentionally public assets should have public access blocked. This is a single checkbox in the AWS console.
Why These Misconfigurations Persist
The frustrating reality is that most misconfigurations aren't the result of ignorance — they're the result of context switching.
- The developer who forgot the subdomain left the company. Nobody else knew it existed.
- The CORS header was added under deadline pressure and "fix later" never happened.
- The S3 bucket policy was copied from a bucket that was correctly used for public assets.
Configuration state accumulates silently. There's no alarm when a DNS record becomes a takeover candidate. There's no notification when a bucket's access policy changes. Security drift happens between scans.
The Only Defence: Continuous Visibility
Misconfiguration-based breaches have one thing in common: they could all have been prevented by knowing they existed.
An exposed subdomain is harmless until someone claims it. A CORS wildcard is harmless until an attacker exploits it. A public bucket is harmless — briefly — until its contents are downloaded.
The window of safety is the period between when the misconfiguration is created and when an attacker discovers it. That window shrinks every day. Automated tools scan continuously. Your discovery cadence needs to match.
This is why weekly external scanning matters more than an annual penetration test. The configuration you had in January is not the configuration you have in June. Every deployment, every DNS change, every new subdomain is a potential new exposure.
The question isn't whether you have misconfigurations. Every business does. The question is how quickly you find out.