When people hear PCI-DSS, they often think about audits, checklists, or compliance paperwork. For application security engineers, that approach fails.

You don't secure payment data by memorizing requirements you secure it by understanding how APIs fail in practice. PCI-DSS is something much more practical:

A set of security constraints that directly shape how applications handle, expose, and protect payment data.

If you build or test applications that touch cardholder data, PCI-DSS is not optional it defines your security boundaries.

That's why often we see it mentioned in job descriptions and audits:

"Must be PCI-DSS compliant."

Cool. Compliant with what, exactly?

It wasn't until I followed APIsec University's AppSec learning path and applied it to a hands-on lab the Damn Vulnerable Bank (DVBank) that PCI-DSS stopped being abstract and started feeling… obvious.

This article is for you if:

  • You've heard of PCI-DSS but don't really know what it does
  • You're interested in AppSec or APIs
  • You learn better by seeing things break than by reading standards

No audit jargon. Just real examples.

1. What Is PCI-DSS (in Human Terms)?

PCI-DSS exists for one reason:

To stop payment card data from leaking when systems fail , because they always do.

It's not about encryption checkboxes. It's about answering simple questions like:

  • Who can see card data?
  • How much of it?
  • Through which APIs?
  • And what happens when something goes wrong?

APIsec University helped frame PCI-DSS as a design problem, not a compliance problem so I tested that idea using a vulnerable banking app.

2. The Lab Setup (Nothing Fancy)

To really understand PCI-DSS, I needed something breakable. So I used:

  • Damn Vulnerable Bank (DVBank) a purposely insecure banking API
None
  • APIsec University materials to guide what to test
None
  • Postman + browser DevTools
None
  • A regular user account (not admin)

Every example in this article comes from my own DVBank lab testing not theory.

3. The Moment PCI-DSS Clicked for Me: The API That Returned Too Much

While exploring the app as a normal user, I noticed a request fetching card information.

So I replayed it manually:

None

What came back surprised me. Not just the card number but:

  • Internal identifiers
  • Card metadata
  • CVV values

This wasn't hacking. This was the API doing exactly what it was programmed to do.

Why This Is a PCI-DSS Problem (Without Quoting the Standard)

PCI-DSS basically says:

"Some pieces of card data are too sensitive to ever come back in an API response."

CVV is one of those things. The API didn't:

  • Filter fields
  • Mask values
  • Limit exposure

It just returned the database object.

Lesson #1

If your API returns more than the UI needs, PCI-DSS is already unhappy.

4. When Browsers Become the Enemy (CORS)

This one felt sneaky. By tweaking the Origin header in a request, I noticed the API happily responded with:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
None

Translation for non-security folks:

"Any website can make authenticated requests to this API."

That means:

  • A malicious website open in your browser could silently read banking data

No malware required.

Lesson #2

PCI-DSS includes browser behavior, even if you think you're just building an API.

5. The Big Pattern I Started Seeing

After multiple DVBank tests, a theme emerged, PCI-DSS failures weren't about:

  • Weak crypto, Fancy exploits, Nation-state attackers….

They were about:

  • Trusting the client
  • Returning full objects
  • Skipping ownership checks
  • Assuming "nobody will try that"

APIsec University calls these design-level API flaws and PCI-DSS is basically a list of ways those flaws hurt card data.

Final Thought

If you're learning AppSec or APIs and PCI-DSS feels overwhelming:

Start here:

  • Learn how APIs fail
  • Learn how data leaks
  • Learn how attackers think

Compliance will follow.