If you’re subject to PCI compliance, you’ve got until March 2024 to get your APIs under control. The Data Security Standard has existed since the dawn of PCI, and a brand new version, 4.0, was released in 2023. This is the first major update to DSS in almost ten years. And while 3.0 doesn’t mention APIs at all, they are prominent in 4.0. And for good reason - here’s why:

‍

First, APIs are everywhere - they’re powering almost every online transaction and every web and mobile app. Second, APIs are under attack - Gartner has been saying APIs are the #1 attack vector for years, and the data bears this out - the attacks just keep coming - And they’re more successful than ever. Thirdly, security teams are struggling to keep up - APIs are seriously under-secured, our application security tools just don’t cut it, and testing is lacking, making APIs ripe targets for attackers.

‍

So, let’s look at the DSS requirements and see what they say. Just to make the point really clear, let’s start with the latest version, 3.2.1. There are no mentions of APIs at all, but when you look at the new 4.0 version, APIs are definitely on the radar. 

‍

If you’re familiar with DSS, you know it has 12 major categories, but the one you need to focus on is Requirement 6, Which is to develop and maintain security systems and software. The first thing to notice is this term “bespoke and custom software” - it’s ALL OVER requirement 6 - and it has huge implications for APIs - why? Because APIs are integral to your bespoke and custom software. There’s no question your web and mobile UIs are part of your software stack. Well, your APIs are just another interface - a machine interface - but it’s got just as much access as your UIs do - and actually often more

‍

What’s changed?

6.2.1 

Bespoke and customer software are developed securely. What does it mean? Make sure your dev teams are using the best app security practices. They specifically call out understanding how your data can be accessed and making sure that’s done securely. Remember, APIs are just another interface like your UIs. 6.2.1 tells you to ensure your APIs are as secure as every other interface.

6.2.2

Annual developer training - DSS requires annual training on secure coding techniques for all engineers involved in bespoke and custom software development. They also want you to include training for security testing tools to find vulnerabilities. Remember that 4% figure from before - don’t let that be you - ensure you include security testing for your APIs.

6.2.3 

Software code reviews - of course, you need to do code reviews, which must be done before anything goes to production to find any vulnerabilities. DSS explicitly flags APIs and any other 3rd party components to make sure they’re being used securely. 

6.2.4 

Prevent common vulnerabilities - I call this the OWASP section of DSS 4.0 because you’ve got the kitchen sink of vulnerabilities to worry about - injections, cross-site scripting, authentication attacks, authorization flaws, even attacks on business logic through “attempts to abuse or bypass application features and functionalities through the manipulation of APIs.”

6.3.1 

Security vulnerabilities are identified and addressed - be sure not to miss this requirement: “Vulnerabilities for bespoke and custom software are covered.” If your application has logic flaws, they’ll get exposed through your APIs - so make sure you’re testing these to find them. And if you’re doing bug bounties, ensure you’re including APIs in the programs.

6.3.2 

Software inventory - you have to know what you’ve got to be able to start securing it. This means having an accurate, up-to-date “inventory of bespoke and custom software… to facilitate vulnerability and patch management.” DSS specifically highlights vulnerabilities in 3rd party APIs as these can “render those applications vulnerable to attack.”

6.4.1 

Attack protection - here, you need to a) perform periodic vulnerability testing and b) implement threat detection and blocking. That testing better includes your APIs because you know attackers will be looking at them. And your blocking technology better be API savvy. And seriously - pressure test the hell out of your APIs before any code goes live. 

7.0 

Access Controls is all about who can access system components and cardholder data. And yes, if your APIs have access to this info, you better analyze your policies here. Better yet, follow the “least privilege” / “need to know” model - and test test test - see what’s possible through your APIs.

10.0 

Logging & monitoring - you’re probably already capturing and analyzing logs. But are you collecting API-level activity, too? The best practice here is to use an API gateway - it’s a great way to control access AND capture all that activity.

11.0 

Security Testing - I can’t say it any better than DSS does - “bespoke and custom software should be tested frequently.” And by that, they mean 1) continuous and 2) shift left testing ahead of production.

‍

Conclusion 

That was a whirlwind review of DSS 4.0. Please check out our course, API Security for PCI Compliance, to understand that in detail. You have until March 31, 2024, to prepare your API program. We’re here to help. First, make sure your developers get trained on API security risks. We recommend enrolling them in the API Security Fundamentals course, which is 90 minutes, and you can even deploy the course in your LMS. And second, download our Self-Assessment/Readiness worksheet. This will help you understand where you stand now and what areas need help.