Coupang Data Breach – Key Leak & Architecture Failure

Coupang Data Breach: How One Key Exposed (Almost) Everyone

The recent Coupang data breach was not just an operational mistake. It was a structural security failure that had been effectively “designed in” from the architecture stage.

During the National Assembly hearing:

  • Rep. Lee Hae-min highlighted issues in access control, organizational security, and cloud governance.
  • Rep. Lee Jun-seok focused on the technical flaws in the system design itself.

This article is a developer-focused summary of one core question:

How did one leaked signing key enable a near-nationwide data breach?

1. Coupang’s Initial Explanation: “A Signing Key Was Leaked”

Coupang’s initial public explanation was simple:

“A key used to generate authentication tokens was leaked, and that caused the incident.”

But this immediately raises a technical question:

If only the key was leaked, how did the attacker generate tokens for tens of millions of users?

2. The Real Answer: It Wasn’t Hacker Skill—It Was Bad Architecture

The key leak alone was not enough to guarantee a massive breach. What turned it into a disaster was the surrounding security architecture.

At a high level:

  • The attacker had a powerful signing key.
  • Coupang’s system design effectively turned that key into a master key for everyone.

Four major structural failures made this possible.

3. Failure #1 – Predictable User IDs (1, 2, 3…)

The hearing confirmed that Coupang’s user primary keys in the database were simple auto-incrementing integers:

1 → user #1
2 → user #2
3 → user #3
...

This means an attacker did not need to know emails or phone numbers. They could simply enumerate user IDs from 1 up to N.

If external-facing identifiers had been randomized (UUIDs, snowflake IDs, or hash-based IDs), large-scale automated token minting would have been dramatically harder or effectively impossible.

4. Failure #2 – Internal Token API Exposed to the Internet

There was an API that should have been internal-only, but it was reachable from the public internet.

Conceptually, it behaved like this:

POST /internal/token
{ "user_id": 12345 }  →  returns a signed auth token for that user

This sort of endpoint should exist only:

  • Inside a VPC or private subnet,
  • behind a service mesh with mTLS,
  • or behind an API gateway with strong IAM/mTLS.

Instead, based on the hearing, it was:

  • Publicly reachable from the internet,
  • lacking proper authentication and authorization,
  • not adequately firewalled or isolated.

Once the signing key was leaked, this effectively became a public “token printer” for any user ID the attacker supplied.

5. Failure #3 – A Single, Overpowered Signing Key

Coupang appears to have used a single secret key capable of signing tokens for any account.

In a safer design, you would:

  • Separate keys for user tokens vs. admin tokens vs. internal service tokens,
  • Scope keys with audiences and purposes,
  • Rotate keys regularly and revoke compromised keys quickly.

By contrast, a single “master key” creates a massive single point of failure. Once that key is leaked, the entire trust boundary collapses.

6. Failure #4 – Weak Authorization & Internal Controls

From Rep. Lee Hae-min’s questioning, several internal security issues became visible:

  • MFA that could be bypassed or sidestepped by internal roles,
  • Developers having broad access to production customer data,
  • Sensitive data stored in forms close to plaintext,
  • An access control layer that was weak, inconsistent, or effectively not enforced.

This means that the compensating controls that could have limited the blast radius were also not functioning properly.

7. Likely Attack Flow

1. Obtain the leaked signing key.
2. Discover or know the token-minting endpoint.
3. Enumerate user_id = 1..N (because IDs are predictable).
4. Call the exposed API to mint valid tokens for each ID.
5. Use those tokens to pull personal data at scale.

And the System Provided Ideal Conditions

  • Predictable, sequential user IDs,
  • An internal-style token API exposed to the public internet,
  • A single, all-powerful signing key,
  • Weak or missing authorization checks,
  • No effective rate limiting, WAF, or anomaly detection.

In other words, the architecture turned one leaked key into a near-perfect environment for mass exploitation.

8. Developer Perspective: Why This Architecture Should Never Exist

1) Do Not Expose Auto-Increment PKs Externally

Auto-increment integers are fine as internal DB primary keys, but they are dangerous as external-facing identifiers. Once exposed, they make “ID = 1..N” enumeration trivial.

Better patterns:

  • Random IDs (UUIDv4, snowflake IDs),
  • Hash-based external user IDs,
  • Clear separation between internal PK and external-facing ID.

2) Token-Minting APIs Must Be Internal-Only

Any endpoint that can directly mint tokens for arbitrary accounts belongs strictly inside private infrastructure:

  • Private subnets / VPC-only networks,
  • Service meshes with mTLS,
  • Or API gateways enforcing strong authentication.

Exposing such an endpoint publicly is equivalent to handing out a token printer.

3) JWT-Style Signing Key Management

For JWT or any signed token format, a leaked key is inherently dangerous. That’s why systems must:

  • Split keys by purpose (user vs. admin vs. internal),
  • Scope tokens via audiences/claims,
  • Implement key rotation and revocation.

A single universal signing key is fundamentally at odds with secure, large-scale design.

4) Authorization Is a Separate, Required Layer

Even if a token is validly signed, the system must still ask:

“Is this token allowed to perform this action on this resource, right now?”

That requires a dedicated authorization layer that checks:

  • Subject vs. resource (e.g., user ID matches account),
  • Roles/attributes (RBAC/ABAC),
  • Context (risk signals, IP, device, time, etc.).

9. What a Safer Architecture Could Have Looked Like

  • Random external user IDs: Use UUIDs or similar for anything exposed outside.
  • Internal PK isolation: Never expose raw DB primary keys in public APIs.
  • Internal-only token minting: Confine token-issuing endpoints to private networks.
  • Key separation: Different keys for different token types and scopes.
  • Authorization layer: Validate permissions beyond “token is valid.”
  • Rate limiting & WAF: Detect and block bulk enumeration or suspicious spikes.
  • Least privilege & encryption: Minimize who and what can see raw personal data.

Even if a signing key had still leaked under such a design, turning that leak into a country-scale breach would have been much harder or practically infeasible.

10. Conclusion: A Predictable, Man-Made Disaster

Coupang failed to follow a set of fundamentals that modern web services treat as baseline:

  • Safe identifier design,
  • Separation of internal vs. external APIs,
  • Secure key management,
  • Robust authorization,
  • Data protection and governance,
  • Cloud and network security architecture.

The problem was not simply that a key was stolen. The problem was that this one key could be used to impersonate virtually every user in the system.

The hearing made this structurally and technically clear. Going forward, what is needed is accountability, a fundamental security redesign, stronger national guidance on cloud platform security, and above all, genuine security-by-design from the first architecture diagram.