API security for PCI compliance: A deep dive into the PCI DSS 4.0 impact

There are more than 50 new requirements in PCI DSS v4.0 – do you know which ones apply to you and what you need to do to meet them?  The March deadline is approaching, and we want to ensure you're fully prepared for the changes ahead.

The deadline for compliance in the first phase (with 13 broad new requirements) of PCI DSS 4.0 is March 31, 2024. The implementation deadline for a second phase, comprising requirements of a mostly more technical nature, follows a year later.

For the complete list of new requirements, including those that are effective immediately and those that are effective on 31 March 2025, review the Summary of Changes. 

What are the consequences of PCI non-compliance? Think the 2017 data breach at Equifax, resulting in the exposure of personal information, including credit card numbers, of 147 million individuals, led to a significant fine of $425 million. This incident stands out as one of the most prominent violations of PCI standards since their inception.

With APIs playing an increasingly vital role in financial transactions, ensuring their security is synonymous with compliance and the protection of both your business and customers. Dive into this article to discover how to improve your API security in preparation for these impending changes.

The critical role of APIs in payment security

APIs, or Application Programming Interfaces, are the building blocks of digital interactions, enabling software components to communicate and function cohesively. They are the conduits through which data flows, making them a vital element in the ecosystem of e-commerce, open banking, and virtually all online transactions.

API usage is exploding, they now account for more than 83% of the global web traffic, signifying their dominance and the scale of potential risk. Current API trends are driven by developers, which include the move toward more developer-friendly, lightweight API gateways, as well as the rise of GraphQL,

Financial APIs are a lucrative target for cybercriminals due to the sensitive financial data they handle.

In 2023 nearly 70% of financial services and insurance companies have encountered rollout delays due to API security issues. Also, 92% of them have experienced security problems in their production APIs, with approximately one in five suffering an API security breach.

Notably, 84% of attacks on financial services and insurance originated from "authenticated" users who appeared legitimate but were, in fact, malicious attackers. This suggests that API security tools are not adequately equipped to prevent API attacks.

The alarming trend of API attacks underscores the need for robust security measures.

Understanding PCI DSS 4.0: A paradigm shift in compliance

PCI DSS 4.0 marks a significant update to the standards, reflecting the changing dynamics of digital commerce and the need for more stringent security protocols. This iteration is not merely an incremental change but a comprehensive overhaul that addresses the current and future landscape of payment security.

One of the most notable inclusions in PCI DSS 4.0 is the explicit mention of APIs, which were not previously singled out in the standards. This change acknowledges the critical nature of APIs in the payment processing chain and the necessity to secure them diligently.

Applicable security requirements for the APIs can be found in the following requirements:

Requirement 2. Secure service 

Requirement 2 of PCI DSS focuses on securing system components. While there haven't been significant changes between PCI DSS 4.0 and 3.2.1 specifically for API security under Requirement 2, there are general security measures that organizations should implement for API security, which may align with both versions:

In 2024:

• Implement segregation of duties to ensure that access to API components is restricted to authorized personnel only. This includes adhering to Requirement 2.1.2, which requires each server to host only one primary function to prevent functions with different security requirements from co-existing on the same server.

• Enhance access controls to prevent unauthorized access to API resources, aligning with Requirement 2.1.7, which mandates establishing secure configuration standards for all system components, including APIs.

Also don't forget about requirement 2.2.7 - All non-console administrative access is encrypted using strong cryptography:

In the context of API security, ensuring that administrative access to API management systems, configuration interfaces, and other administrative functionalities is encrypted using strong cryptography is crucial. If these administrative interfaces were accessed over unencrypted channels, such as HTTP instead of HTTPS, sensitive authentication credentials and administrative commands could be intercepted by malicious actors.

By encrypting non-console administrative access, including access to API management systems, organizations can mitigate the risk of credential interception and unauthorized access to APIs. This helps prevent potential attacks where attackers eavesdrop on administrative traffic to obtain API keys (though we have shown in our State of API Security 2024 report that you can obtain API keys without listening to the traffic), authentication tokens, or other sensitive information, which could then be used to gain unauthorized access to APIs, manipulate data, or launch further attacks on the system.

Requirement 4. Protocol configurations used by the API

In PCI DSS 4.0, there were no specific changes to Requirement 4 that directly targeted API security. However, organizations should ensure that their API implementations comply with this requirement by encrypting the transmission of any cardholder data over public networks, such as the internet, using strong cryptographic protocols like TLS (Transport Layer Security). Compliance with this requirement ensures data integrity and confidentiality, mitigating the risk of interception and unauthorized access to sensitive information exchanged via APIs.

Requirement 6. Use of secure development practices to mitigate and address vulnerabilities

Secure Software Development Lifecycle (SSDLC)

PCI DSS 4.0 emphasizes the importance of a Secure Software Development Lifecycle (SSDLC), advocating for security to be embedded in every phase of software development. This proactive approach ensures that security considerations are not an afterthought but a foundational aspect of the development process.

Developers play an important role (when are they not?), requiring comprehensive training in secure coding practices and the use of security testing tools. The standard mandates annual developer training, underscoring the need for continuous education to keep pace with the evolving threat landscape.

Zoom in on requirements

Requirement 6 of PCI DSS 4.0 focuses on secure software development practices, particularly concerning bespoke and custom software components. Here are some key differences and updates in Requirement 6 within the context of PCI DSS 4.0:

• Expanded Scope: PCI DSS 4.0 clarifies that Requirement 6 applies to all system components, except for Requirement 6.2, which specifically addresses bespoke and custom software developed for or by the entity. This clarification helps organizations understand the applicability of Requirement 6 to different types of software within their environments.
• Training and Awareness (6.2.2): PCI DSS 4.0 emphasizes the importance of training and awareness for personnel involved in bespoke and custom software development. Sub-requirement 6.2.2 requires organizations to provide training to software developers on secure coding practices, vulnerability identification, and mitigation techniques specific to the development of custom software components, including APIs.
• Code Review and Release (6.2.3): The requirement for reviewing custom software prior to release (6.2.3) has been refined in PCI DSS 4.0. The sub-requirement now distinguishes between general code review practices and those specifically needed for manual code reviews. This clarification helps organizations establish robust processes for reviewing and validating custom software, including APIs, before deployment.
• Addressing Coding Vulnerabilities (6.2.4): PCI DSS 4.0 consolidates requirements for addressing common coding vulnerabilities under sub-requirement 6.2.4. This update streamlines the guidance for mitigating common software vulnerabilities, such as injection flaws and buffer overflows, into a single requirement. Organizations are encouraged to implement comprehensive controls to prevent or mitigate these vulnerabilities in bespoke and custom software, including APIs.
• Inventory Management and Governance (6.3.2.): Requirement 6.3 in PCI DSS 4.0 includes provisions for identifying security vulnerabilities and protecting system components from vulnerabilities via patching. 6.3.2 introduces a new requirement for organizations to maintain an inventory of bespoke and custom software. This requirement underscores the importance of tracking and managing software assets developed internally or customized for specific business needs, including APIs.

A comprehensive inventory of APIs is a cornerstone of effective API security governance. PCI DSS 4.0 requires organizations to maintain an up-to-date inventory of all bespoke and custom software, including APIs. This inventory serves as the foundation for risk assessment, security testing, and incident response.

Governance extends beyond inventory management to include the establishment of policies and procedures that dictate how APIs are developed, deployed, and maintained. Centralized management through automated API discovery and inventory tools like Escape help enforce consistent security policies and prevent the proliferation of "shadow" or "zombie" APIs that may escape scrutiny.

• New requirement 6.4.2 (to be implemented by March 2025) mandates deploying automated technical solutions for public-facing web applications to detect and prevent web-based attacks. This ensures continuous protection against common threats such as injection attacks and cross-site scripting (XSS). While directly targeting web applications, organizations should also consider the implications for APIs interacting with these applications or providing critical functionalities to external users. This requirement emphasizes the proactive defense against evolving cyber threats and underscores the importance of implementing automated protection mechanisms to safeguard sensitive data and ensure compliance with PCI DSS standards.

Requirement 7. Appropriate authentication & Requirement 8. Authorization of users 

PCI DSS 4.0 introduced several updates and refinements compared to version 3.2.1, particularly concerning API security.
Here are some significant changes between the two versions:

• Enhanced Authentication and Access Controls: PCI DSS 4.0 introduces stricter requirements for authentication and access controls for APIs. This includes robust authentication mechanisms such as multifactor authentication (MFA) to verify user identities and strong access controls to restrict access to sensitive API resources. For example, users accessing sensitive API endpoints may need to provide both a password and a one-time code sent to their mobile device.

• Improved User Identification and Session Management: The standard mandates organizations to enhance user identification and session management for API access. This involves implementing unique user IDs, strong password policies, session timeout mechanisms, and monitoring session activities to prevent unauthorized access.

• Strengthened Logging, Monitoring, and Access Reviews: PCI DSS 4.0 emphasizes the importance of logging, monitoring, and access reviews for API security. Organizations are required to log all API activities, including requests and responses, and conduct regular reviews and audits to identify and remediate unauthorized access attempts or excessive privileges.
• Enhanced Authentication Mechanisms: The standard requires organizations to strengthen authentication mechanisms for API access, including the implementation of strong encryption protocols, secure tokenization methods, and secure key management practices to protect API credentials and prevent unauthorized access.

Requirement 11. Conducting regular vulnerability assessments 

The new standard calls for frequent and thorough testing of APIs to uncover vulnerabilities before they can be exploited. This includes both dynamic application security testing (DAST) and penetration testing, which simulate real-world attack scenarios to identify weaknesses.

The concept of "shifting left" is also prominent in PCI DSS 4.0, advocating for security testing to occur earlier in the development cycle. This shift enables organizations to identify and remediate vulnerabilities before software reaches production, reducing the risk of exposure and the cost of fixes.

When focusing on API security in the context of Requirement 11 of PCI DSS, it's important to consider how the changes introduced in PCI DSS 4.0 impact API security practices:

• Enhanced Vulnerability Scanning: The introduction of Requirement 11.3.1.2 emphasizes the need for internal vulnerability scans via authenticated methods. For APIs, this means conducting thorough scans to identify vulnerabilities within API components and associated infrastructure. Authenticated scanning provides deeper insights into potential API vulnerabilities, such as authentication weaknesses, insecure endpoints, or inadequate access controls.
• Comprehensive Vulnerability Management: Requirement 11.3.1.1 highlights the importance of managing non-high-risk vulnerabilities identified during internal scans. This requirement extends to API security, where organizations must establish processes to track, prioritize, and remediate vulnerabilities specific to APIs (where Escape API Security platform) can help 🙂). This includes vulnerabilities in API endpoints, data validation mechanisms, encryption protocols, and access controls.

How to ensure PCI compliance for your APIs?

We've already covered several details in the paragraphs above. To sum up, to ensure PCI compliance for your APIs, take a comprehensive approach:

1. Robust authentication: Implement multi-factor authentication and strong access controls to authenticate users and protect sensitive data access.
2. Encryption standards: Utilize industry-standard encryption protocols like TLS to encrypt data transmission, ensuring cardholder information remains secure in transit.
3. Access management: Employ role-based access controls (RBAC) and least privilege principles to limit API access to authorized personnel only, reducing the risk of unauthorized data exposure.
4. Continuous monitoring: Implement real-time monitoring and logging mechanisms to track API activity, detect anomalies, and respond promptly to security incidents.
5. Rigorous testing: Conduct regular vulnerability assessments, penetration tests, and code reviews to identify and remediate API vulnerabilities before they can be exploited by attackers.
6. Compliance documentation: Maintain detailed records of security measures, audits, and compliance activities to demonstrate adherence to PCI DSS requirements during assessments and audits.

Don't forget, the vulnerabilities inherent in APIs—such as weak authentication, flawed authorization checks, and business logic errors—can lead to significant breaches, resulting in the exposure of cardholder data.

Leveraging resources for PCI compliance and API security

To navigate the complexities of PCI DSS 4.0 and API security, organizations can tap into a wealth of resources. Educational blogs, checklists and hands-on trainings like Escape API Security blog or Escape API Security Academy offer specialized guides and that delve into the nuances of API security in the context of PCI compliance. These courses provide actionable insights and practical knowledge to secure APIs effectively.

For organizations seeking a structured approach to compliance, self-assessment worksheets and API security checklists can be invaluable tools.

The road ahead: Preparing for the March deadline

With the March deadline for PCI DSS 4.0 compliance on the horizon, organizations must act swiftly to align their API security practices with the new standards. The transition period offers a window of opportunity between 2024 and 2025 to assess current security postures, implement necessary changes, and ensure that all aspects of API security are addressed.

The journey to compliance is ongoing, and the stakes have never been higher. As digital transactions continue to grow in volume and complexity, the security of APIs will remain a critical concern. PCI DSS 4.0 is a call to action for organizations to improve their API security, protect cardholder data, and maintain the trust of customers.