Cloud and API Security: The Small Mistakes Behind Big Breaches

Most cloud breaches I read about do not start with a brilliant zero-day. They start with something small and boring: a role that collected one permission too many, an API nobody remembered to switch off, a token that outlived the job it was created for. Each mistake looks harmless on its own. The damage comes when two or three of them line up.

In October 2025, Harvard Business Review Türkiye published an article by Can Polat that makes exactly this argument. He says cloud and API security should be treated as a systemic problem, not a list of individual holes, and he describes a set of “advanced patterns” that classic controls tend to miss. I like the framework. My one criticism is that every scenario in the article is illustrative: no real incident, no source. So in this post I keep his structure and attach each pattern to a breach that actually happened and was publicly investigated.

Four surfaces, connected

The article splits the attack surface into four familiar areas:

  • Identity and access. Identity, not the network, is now the main control surface. The danger is permissions that quietly grow over time.
  • APIs and services. Undocumented “shadow” APIs escape review, testing and monitoring.
  • Workloads and environments. Containers and serverless functions appear and disappear in minutes, so one bad default is copied at scale.
  • Visibility and policy. Periodic scans give you snapshots. Cloud environments need continuous policy enforcement and anomaly detection.

The key point is that these areas are not independent. A small privilege change in identity can open a hidden API endpoint, and a new container can bypass a policy check. Real breaches almost always happen where the areas meet. The cases below show what that looks like in practice.

1. Permission drift: Capital One (2019)

The pattern. Roles slowly collect broad rights, usually for convenience, and nobody removes them. The article calls it “permissive by default”: unless access is actively pruned, it only grows.

What happened. An attacker exploited a misconfigured web application firewall running on AWS with a server-side request forgery (SSRF) attack. She tricked the firewall into calling the cloud metadata service, which handed over the temporary credentials of the firewall’s IAM role. That role had far more rights than a firewall needs: it could list and read the company’s storage buckets. The result was more than 100 million credit card applications stolen.

The lesson. The SSRF bug opened the door, but over-broad permissions decided how much was taken. A firewall role scoped to what a firewall actually does would have turned a major breach into a minor incident. That is why the article insists on least privilege and on treating IAM changes like code: reviewed, version-controlled and tested against permission boundaries.

2. Shadow and forgotten APIs: Optus (2022) and T-Mobile (2023)

The pattern. APIs that are not in the official inventory have no code review, no monitoring and often no owner. The article’s rule of thumb: if you run 50 known services but your logs show calls to 60 or 70 different endpoint patterns, you have shadow APIs.

What happened at Optus. According to the Australian communications regulator ACMA, a coding error in 2018 broke the access controls of an API. In 2021 Optus found and fixed the error on its main domain, but not on a second, dormant domain that was still connected to the internet. That domain stayed vulnerable for about two years. In September 2022, an attacker reached it and pulled the records of about 9.5 million current and former customers. ACMA described the attack as “a simple process of trial and error”. Optus disputes that description.

What happened at T-Mobile. In its SEC filing, T-Mobile reported that an attacker had been pulling data through one API since around 25 November 2022. The activity was only detected on 5 January 2023, after roughly six weeks. Data from about 37 million customer accounts was taken, including names, addresses, phone numbers and dates of birth.

The lesson. Optus shows that fixing a bug is not enough if you do not know every place the same code is deployed. T-Mobile shows that an API that works exactly as designed can still be a leak if nobody watches how it is used. Both point to the article’s recommendations: continuous API discovery from load balancer and proxy logs, and a rule that no service reaches production without being registered in the API catalog.

3. Missing rate limits: Dell (2024)

The pattern. A public API shows no signs of abuse, yet data is being harvested in bulk. The traffic comes through an endpoint that has no rate limit.

What happened. In May 2024 a threat actor told BleepingComputer how they collected about 49 million Dell customer records. They registered several fake companies in Dell’s partner portal, got access within days without real verification, and then queried an API with randomly generated service tags. They claim they sent about 5,000 requests per minute for three weeks, and that nothing stopped them. Dell confirmed the breach and says it was already investigating before the attacker emailed them. The volume figures come from the attacker and have not been independently confirmed.

The lesson. No single request was malicious. The abuse was only visible in aggregate. Rate limits, per-account quotas and an alert on unusual volume are not optional extras for any API that returns personal data.

4. Forgotten machine identities: Cloudflare (2023)

The pattern. Critical actions happen under identities that nobody can clearly attribute or that everybody assumes are unused: shared keys, service accounts, automation tokens.

What happened. After the Okta breach in October 2023, Cloudflare rotated its credentials. But one service token and three service accounts were not rotated, because the team mistakenly believed they were unused. Out of thousands of credentials, those four were enough. On Thanksgiving 2023, an attacker used them to get into Cloudflare’s Atlassian environment: Jira, Confluence and Bitbucket. They downloaded 76 source code repositories. Cloudflare contained the attack and published an unusually transparent report. Its response included rotating more than 5,000 production credentials and rebuilding every machine in its global network.

The lesson. This is one of the best-run security organisations in the industry, and it still had blind spots in its machine identities. The article’s recommendation follows directly: give every service its own workload identity (for example with SPIFFE), keep an inventory of non-human identities, and treat “we think it is unused” as a reason to revoke, not to skip.

5. Context mismatch in token validation: Storm-0558 (2023)

The pattern. A system accepts a credential in a context it was never meant for. The article describes this mainly for service meshes: a service assumes a call is trusted because it comes from inside the network, so an attacker can skip the identity check by calling a service directly by IP address.

What happened. The best-known example of this pattern happened at the identity layer. In 2023, a China-linked group that Microsoft calls Storm-0558 obtained a Microsoft signing key from 2016 that was meant for consumer accounts. Because of a validation flaw, Microsoft’s systems also accepted tokens signed with that key for enterprise email. The attackers forged tokens and read the mailboxes of about 25 organisations, including the US State Department. The intrusion was discovered by a State Department team using its own audit logs, not by Microsoft. The US Cyber Safety Review Board later called it a “cascade of security failures”.

The lesson. Two patterns met here. A key that should have been retired was still valid years later, and the system that checked tokens did not check what context they belonged to. The service mesh version of the fix is the same idea: enforce mutual TLS between services, require every service to verify the caller’s identity, and never design a network where “internal” means “trusted”.

6. Token lifetime versus exposure: Microsoft AI research (2023) and CircleCI (2023)

The pattern. Long-lived tokens reduce friction, but if one leaks, the exposure lasts as long as the token. The article puts it simply: when the workload dies, its tokens should die too. Its example is a 10-minute lifetime for a token that is normally used for a 5-minute job.

What happened at Microsoft. In 2023, the cloud security firm Wiz found that Microsoft AI researchers had published a storage link in a public GitHub repository. The link carried an Azure SAS token that gave “full control” over an entire storage account, not just the intended files. Its expiry date had been extended to 2051. The token was public for about three years and exposed 38 TB of internal data, including workstation backups, secrets and more than 30,000 internal Teams messages.

What happened at CircleCI. In December 2022, malware on an engineer’s laptop stole a valid single sign-on session cookie. That session had already passed two-factor authentication, so the attacker did not need to pass it again. Using the engineer’s ability to generate production access tokens, the attacker stole customer environment variables, tokens and keys. CircleCI asked all customers to rotate every secret stored on the platform.

The lesson. Strong authentication at the front door does not help if what you hand out afterwards lives too long. Short-lived, automatically renewed credentials (OAuth refresh tokens, a secrets manager like Vault) and secret scanning on every repository shrink the window an attacker can use.

7. Ephemeral environments, permanent mistakes: Tesla (2018) and Codecov (2021)

The pattern. A short-lived cluster or container is built from an old template with too many permissions or a secret baked in. The environment disappears, but the mistake lives on in the template and comes back the next time someone uses it.

What happened at Tesla. In 2018, researchers at RedLock found a Tesla Kubernetes admin console with no password. Attackers had already used it to mine cryptocurrency on Tesla’s cloud resources, and they kept CPU usage low to avoid detection. The console also exposed AWS credentials with access to a storage bucket of vehicle telemetry data. Tesla fixed the issue within days and said the impact was limited.

What happened at Codecov. A mistake in Codecov’s Docker image build process let an attacker extract a credential. With it, the attacker modified the company’s Bash Uploader script so that it sent the environment variables of customers’ CI pipelines (tokens, keys, credentials) to an outside server. The change went unnoticed from 31 January to 1 April 2021, when a customer saw that the script’s checksum did not match the one on GitHub.

The lesson. “Ephemeral” does not mean “exempt from review”. Infrastructure templates and container images deserve the same scrutiny as application code: no default credentials, least privilege at provisioning time, no secrets baked into images, and automated checks in the CI/CD pipeline before anything goes live.

The patterns at a glance

PatternReal caseWhat would have limited it
Permission driftCapital One, 2019Least privilege, IAM changes reviewed like code
Shadow / forgotten APIsOptus, 2022; T-Mobile, 2023Continuous API discovery, mandatory API catalog, usage monitoring
Missing rate limitsDell, 2024Rate limits, quotas, volume alerts, partner verification
Forgotten machine identitiesCloudflare, 2023Workload identities, non-human identity inventory, revoke when unsure
Context mismatchStorm-0558, 2023Strict token validation, key retirement, mutual TLS
Token lifetime vs. exposureMicrosoft AI research, 2023; CircleCI, 2023Short-lived credentials, secret scanning, scoped tokens
Ephemeral environmentsTesla, 2018; Codecov, 2021Infrastructure as code with policy checks, no secrets in images

From firefighting to foresight

The part of the article I agree with most is the last one: every incident should make the system permanently stronger. If you find an unknown endpoint, add automated discovery so the next one is flagged before it is used. If you see a one-off privilege escalation, write a policy test so it cannot be deployed again. Over time, one-off fixes turn into automatic defenses.

The real cases add something the article leaves out: in almost every one of them, the warning signs were there. Optus had already found the bug once. Cloudflare had a rotation plan. T-Mobile’s API was doing exactly what it was built to do. The gap was not knowledge but follow-through, and that is an organisational problem as much as a technical one. Someone has to own the API inventory, the list of machine identities and the lifetime of every token.

What I would recommend to any team running workloads in the cloud:

  • Know what you expose. Compare your API inventory with real traffic every week, not once a year.
  • Give every workload its own identity. No shared keys, and a named owner for every service account.
  • Make credentials expire. Match token lifetimes to real usage and revoke anything you are unsure about.
  • Trust nothing because it is internal. Verify identity on every call between services.
  • Put policy in the pipeline. Check IAM, templates and images automatically before they reach production.

Sources