What Does PCI DSS 4.0 Mean for API?

Payment Card Industry Data Security Standard or PCI DSS 4.0 was released in March 2022 by the PCI Security Standards Council (PCI SSC).

After using PCI DSS 3.2.1 for several years, PCI DSS 4.0 is the latest security standard version designed to protect credit cards, ensuring their secure processing. 

PCI SSC has released this version of the credit card compliance and security standards as the new set of requirements and best practices to be followed by all organizations that collect, store, process, or transmit payment card data.

What are the latest requirements as per PCI DSS 4.0? Does it apply to API security? If yes, how? Keep reading to find out. 

What is PCI DSS Compliance?

PCI DSS is the global standard for entities that collect, store, transmit, process, handle, or accept credit, debit, or prepaid card data, regardless of the volume of processed data must follow.

It is a set of robust processes, security standards, and best practices created by major credit card companies, including Visa, Mastercard, American Express, Discover, and JCB, to protect sensitive cardholder data and authentication data.

PCI DSS compliance enables organizations to ensure the safety and security of cardholder information while protecting the payments being made/ processed. PCI security instills a sense of trust and confidence among cardholders that their information and money are protected. 

Whether the organization processes/ transmits/ manages card data through an app, API, phone, internet, paper, or person, they must follow the rules laid down by this credit card compliance standard.

For every organization, be it an MNC, an e-commerce platform, an online shopping app, or a small coffee shop, PCI DSS compliance is the bare minimum to ensure card and payment safety. 

Data breaches and security incidents involving credit, debit, and prepaid cards have devastating financial, reputational, and legal consequences for organizations.

So, PCI security helps prevent these costs, non-compliance fines, and legal action. 

How is PCI DSS 4.0 Different from PCI DSS 3.2.1?

PCI DSS 4.0 is the latest iteration of the PCI compliance standard and replaces PCI DSS 3.2.1, which was released in 2018.

PCI SSC has been iterating and upgrading this security standard every few years following the fast-changing threat landscape and the changing nature of vulnerabilities in the card-processing ecosystem. 

The critical changes in PCI DSS 4.0 can be summarized as follows: 

• Incorporation of new and innovative methods to combat known and emerging threats.
• Greater flexibility in maintaining card and payment security.
• Greater stress on viewing and treating card security as an ongoing process, not an end goal.
• Improved methods and procedures for payment validation.
• Ensures that the framework and processes follow the changing needs and context of the card-processing and payments ecosystem.
• Allows for customized implementation of security controls to achieve PCI DSS compliance.

Is PCI DSS Compliance Needed for APIs?

Yes. If your APIs are used in processing, carrying, transmitting, or managing credit, debit, or other payment cards, you and your technical partners ensure that your APIs are PCI DSS compliant. 

PCI DSS 4.0 Compliance and APIs

Organizations in online payments widely leverage APIs to help deliver faster and more seamless customer experiences. But APIs expose data, underlying business logic, and functionalities by their very nature. As a result, API processing/ handling online payments has become a big target for cybercriminals. 

This is why PCI DSS 4.0 brings stringent security regulations to ensure robust payment security with far-reaching ramifications for API security.

These regulations are majorly found under requirement 6 of the latest iteration of the PCI DSS standard– Develop and Maintain Secure Systems and Software. Under this section, two specific requirements have ramifications for API security. Here they are: 

6.2 – Bespoke and Custom Software are Developed Securely

Recently, a growing focus has been on the need to deliver secure-by-design apps and software by integrating security into the development stages. This is widely known as the shift-left approach and is what section 6.2 of PCI DSS 4.0 is broadly concerned with.  

It stressed the need for organizations to identify and fix vulnerabilities, flaws, and misconfigurations in apps and APIs as early as possible in the development lifecycle.

This has two powerful benefits: it will not be a big problem in the development stages and will not delay releases.

Two, it will reduce the risk of vulnerabilities entering production and leaving the app, software, or API vulnerable to breaches and security threats. 

In this section, 6.2.3 and 6.2.4 requirements are particularly important to APIs. 

Requirement 6.2.3 requires that all bespoke and custom software/ applications be properly reviewed before they go into production for customer usage. In doing so, organizations can identify and fix potential coding errors and vulnerabilities. 

This definition requires that all APIs also be included in the review process. Organizations need to ensure that their API Swagger files – machine-readable documents that describe the functionality of an API written in OpenAPI specifications – are effectively reviewed and vulnerabilities fixed before going into production. 

By leveraging API-focused security tools like AppTrana, you can cross-reference Swagger files to ensure they are PCI DSS 4.0 compliant, secure, and without vulnerabilities. Such tools can detect differences between incoming API traffic and Swagger files. 

Automating positive security models is a key value proposition for APIs within the AppTrana WAAP ecosystem.

This feature proves advantageous for teams without Swagger and Postman documentation for their APIs. The swagger file can be seamlessly developed automatically through the API discovery feature. Moreover, the managed services team is involved in generating Postman files for critical open APIs.

Requirement 6.2.4 requires that organizations define all methods and techniques software development professionals use to prevent/ mitigate common security attacks and related vulnerabilities in bespoke and custom software. These software attacks could include injection attacks (XSS, SQL, XPatch, command, object, etc.), data and data structure attacks, attacks on cryptography, business logic attacks, access control mechanisms, and attacks via high-risk vulnerabilities.  

Of these, including business logic flaws and attacks is particularly important for the PCI DSS 4.0 compliance of APIs. There have been a growing number of business logic attacks as APIs expose business logic by their very nature and enable attackers to attack APIs more effortlessly. 

Business logic flaws may be introduced into APIs during development, deployment, or updates. When there are more API updates, the chances of introducing business logic flaws are higher. 

This is why PCI DSS 4.0 requires organizations to proactively find and secure business logic flaws in APIs before attackers can find and exploit them. API penetration testing serves as a proactive measure to identify and address these vulnerabilities before they can be leveraged by attackers.

6.4 – Public-Facing Web Applications are Protected against Attacks

Public-facing web applications are always at a higher risk of attacks when compared to non-public-facing and internal applications owing to their widespread exposure to all kinds of users. Section 6.4 concerns itself with the robust protection of such apps, laying down a range of measures to achieve heightened public app security. 

In this section, requirements 6.4.1 and 6.4.2 are particularly important for APIs. Requirement 6.4.1 concerns the proactive, ongoing identification and mitigation of new threats and vulnerabilities.

Organizations can use detective tools – manual and automated – to review and monitor known and emerging threats and vulnerabilities in public-facing apps and APIs. Organizations may also leverage fully managed, intelligent tools for preventive security.  

Requirement 6.4.2 extends on 6.4.1 and stresses the need to be proactive and use preventive controls and tools to find and mitigate API security flaws and threats that put the public-facing application at risk.

Conclusion

Given how ubiquitous and critical APIs are to the payment processing space, the latest version of PCI DSS compliance requirements has wide-ranging ramifications for API security.

That is why you must choose an API security solution that enables you to be PCI DSS 4.0 compliant.