API compliance: Practical approaches for modern development teams

There’s nothing quite like hitting your stride with a large API project. Your rate limiting, authentication, and state management have been debated, designed, built, and tested to perfection. It’s time to start building new features for your growing user base. Bliss.

But right as you’re ready to ship, your in-house counsel emerges from a Patagonia vest catalog asking for “just a short review”. A “quick coffee” is about to turn into the longest month of your life. At best, you’re looking at weeks of meetings and documentation. At worst, your next eight sprints will be spent refactoring for compliance.

It doesn’t have to be this way. By integrating compliance requirements into your development process from the start, you can avoid these last-minute fire drills. This guide explores practical, industry-tested approaches to API compliance that are actually used in the real world.

Let’s start with what each role player wants and think about how we can find common ground:

• Developers need clear, implementable specifications that don’t sacrifice velocity.
• Legal teams require documented controls and evidence for audits and reporting.
• Auditors expect verifiable compliance and a clear audit trail.

Why is compliance so important?

Compliance allows you to avoid paying hefty fines and losing customer trust.

Take, for example, the €290,000,000 GDPR fine Uber had to pay in July 2024 (opens in a new tab) for improperly transferring European drivers’ personal data to servers in the United States. Uber’s API and data infrastructure failed to implement adequate safeguards when transmitting sensitive information, including location data, payment details, identification documents, and in some cases, even criminal and medical records.

This serves as a costly reminder that privacy compliance needs to be designed into APIs from the start, particularly for international data transfers. The cost of retrofitting compliance can far exceed the cost of building it in from the start.

Common compliance frameworks

In an ideal world, we’d have a single, universally accepted compliance framework. In reality, we have a slew of industry-specific standards and regulations. Here’s a comparison of key requirements across major frameworks:

Let’s explore each framework’s specific requirements.

SOC 2: System and Organization Controls

The SOC 2 is the de facto standard for SaaS companies, especially those selling to enterprises. It’s less about specific technical requirements and more about proving you have the proper controls in place.

For APIs, this typically means:

• Access control and authentication
• Audit logs of all data access attempts and changes
• Monitoring and alerting systems
• Documented change management

GDPR: General Data Protection Regulation

If you handle data from EU residents (notice we didn’t say EU citizens), the GDPR applies to you. It’s a comprehensive piece of legislation that gives individuals strong rights over their personal data.

Your API needs to support:

• Data exports in machine-readable formats
• Complete data deletion (“right to be forgotten”)
• Explicit consent tracking
• Data minimization (only collect what you need)

PCI DSS: Payment Card Industry Data Security Standard

If your API handles credit card data, you need to comply with the PCI DSS. Unlike the SOC 2 and the GDPR, it has very specific technical requirements about how you handle, store, and transmit payment data.

The PCI DSS is more prescriptive but focuses on storage and transmission:

• Never store sensitive data (such as CVVs, PINs, or magnetic stripes).
• Encrypt transmissions of cardholder data.
• Restrict access by IP and authentication.
• Log all access attempts and changes.

HIPAA: Health Insurance Portability and Accountability Act

The HIPAA governs the handling of protected health information (PHI) in the United States. Its Security Rule has specific requirements for API implementations:

• Strong access controls with role-based authorization
• End-to-end encryption for all PHI transmission
• Detailed audit trails of all PHI access and modifications
• Automatic session termination after a period of inactivity
• Business Associate Agreements (BAAs) for API integrations
• Secure API key management and rotation

CCPA/CPRA: California Consumer Privacy Act/California Privacy Rights Act

California’s privacy laws give consumers significant rights over their personal information and impose strict requirements on APIs handling Californian residents’ data, including:

• The right to know what personal information is collected and shared
• The right to delete personal information
• The right to opt out of data sharing and selling
• Data portability requirements
• Specific consent requirements for minors
• The requirement to honor Global Privacy Control (GPC) signals

High-impact areas for compliance

By focusing on high-impact areas, like data encryption, access control, audit logging, and data minimization, you can build a solid foundation for compliance.

Data encryption

Ensure that all sensitive data is encrypted at rest and in transit. Use industry-standard encryption algorithms and key management practices.

Access control

Zero trust principles should guide your access control strategy. Implement role-based access control (RBAC) and least privilege access to limit exposure.

Audit logging

Log all access attempts, changes, and deletions of sensitive data. Ensure logs are tamper-proof and stored securely.

Data minimization

Only collect data that is necessary for your service to function. Regularly review data storage and retention policies.

Common security risks in API development

A large part of compliance is about avoiding common security issues. Resources such as the OWASP API Security Top 10 (opens in a new tab) provide a good starting point for understanding potential threats. Here are some common security risks to watch out for:

Broken object level authorization

This occurs when APIs don’t properly verify that the requesting user has permission to access or modify a specific resource. For example, without adequate verification, a user might be able to access another user’s data by manipulating an ID in the request URL.

Prevent this by implementing proper access controls and authorization checks at the object level, such as verifying that the requesting user has the necessary permissions to access the requested resource.

Row-level security can be implemented in the database or at the application level, depending on the use case.

Broken authentication

Authentication mechanisms that are implemented incorrectly may allow attackers to impersonate users or bypass authentication entirely.

Prevention strategies:

• Use standard authentication frameworks rather than custom implementations.
• Implement proper token validation, revocation, and expiration.
• Enforce strong password policies and multi-factor authentication.

Broken object property level authorization

Further vulnerabilities (formerly known as the “Excessive Data Exposure” and “Mass Assignment” security vulnerabilities) occur when APIs expose sensitive properties or allow properties that should be restricted to be updated.

Prevention strategies:

• Restrict responses by using explicit schemas to control what APIs return.
• Restrict inputs by allowlisting certain properties for updates.

Unrestricted resource consumption

APIs that don’t properly limit resource usage may allow attackers to launch denial-of-service attacks or cause excessive operational costs.

Prevention strategies:

• Implement rate limiting and quotas.
• Set maximum sizes for payloads, pagination limits, etc.
• Monitor and set alerts for unusual usage patterns.

Broken function level authorization

This occurs when APIs don’t properly restrict access to certain functionality based on user roles or permissions.

Prevent broken function level authorization by implementing RBAC and ensuring each API endpoint checks the users’ permissions before executing requested actions.

Unrestricted access to sensitive business flows

APIs that offer unrestricted access allow for the automated abuse of business functionalities, such as ticket scalping, mass account creation, or content scraping.

Prevention strategies:

• Implement CAPTCHA or anti-automation for sensitive flows.
• Apply business-specific rate limits.
• Monitor unusual patterns of behavior.

Server-side request forgery

Vulnerabilities may allow attackers to make an API server send requests to unintended destinations, potentially accessing internal services.

Prevention strategies:

• Validate and sanitize all input.
• Use allowlists for external service calls.
• Implement network-level protections, like firewalls.

Security misconfiguration

Insecure default configurations, incomplete setups, and exposed cloud storage all put your API at risk.

Prevention strategies:

• Remove debug endpoints in production.
• Keep dependencies up to date.
• Use secure defaults for all configurations.

Improper inventory management

This occurs due to poor visibility into which APIs are deployed, including outdated, unpatched, or undocumented endpoints.

A good service catalog can help you keep track of all your APIs, including their purpose, owner, and compliance status. Kong’s Service Catalog (opens in a new tab) is a good example of a tool that can help you manage your API inventory.

Unsafe consumption of APIs

This vulnerability occurs when your API consumes and processes data from third-party APIs without proper validation.

Prevention strategies:

• Validate all data from third-party APIs.
• Implement timeouts and circuit breakers.
• Apply the same security controls to third-party data as user input.

Practical approaches to API compliance

Let’s explore proven, real-world methods that organizations are successfully implementing today to address compliance requirements in their API development.

Using a modern API gateway

Modern API gateways like Kong, Apigee, and AWS API Gateway provide built-in compliance tools. By centralizing compliance controls in the gateway, you can enforce policies consistently across all APIs and reduce the burden on individual services.

This also simplifies audit preparations by providing a single point of control.

The key features of modern API gateways include:

• Request/response transformation: Remove sensitive data before it leaves your network.
• Rate limiting: Prevent abuse and protect against DDoS attacks.
• IP restriction: Whitelist trusted IP ranges.
• Key authentication: Secure your APIs with API keys.
• ACLs: Control access based on user roles.
• Logging: Centralize access logs for auditing.

# Example Kong plugin configuration for PCI DSS compliance
plugins:
  - name: request-transformer
    config:
      remove:
        headers: ["authorization"]
  - name: response-transformer
    config:
      remove:
        json: ["$.card.number", "$.card.cvv"]
  - name: rate-limiting
    config:
      second: 5
      minute: 60
  - name: ip-restriction
    config:
      whitelist: ["192.168.1.1/24", "10.0.0.1/16"]
  - name: key-auth
    config:
      key_names: ["api-key"]
  - name: acl
    config:
      whitelist: ["admin", "payment-service"]
  - name: log
    config:
      service_token: "log-token"
      log_level: "info"

This approach provides:

• Centralized policy management
• Consistent enforcement across services
• Automated testing of policies
• Clear audit trails

Policy as code

Policy-as-code tools like Open Policy Agent (OPA) allow you to define compliance policies as code that can be versioned, tested, and automated.

The policies are written in a declarative language called Rego, which is designed to remove ambiguity and make policies machine-readable. By removing policy enforcement from the application code, you can ensure that compliance requirements are consistently enforced across all services and updated independently of the application code.

# Example OPA policy for GDPR compliance
package gdpr

# Rule to check if a request requires explicit consent
requires_consent {
  input.resource.type == "user_data"
  data.sensitive_fields[_] == input.action.field
  not input.subject.has_consent
}

# Rule to enforce data deletion (right to be forgotten)
allow_deletion {
  input.action.type == "delete"
  input.resource.owner == input.subject.id
}

# Rule to check if data minimization principles are followed
violates_data_minimization {
  input.action.type == "collect"
  not data.required_fields[input.action.field]
}

This approach provides:

• Centralized policy management
• Consistent enforcement across services
• Automated testing of policies
• Clear audit trails

Compliance-focused API testing

Automated testing designed for compliance can catch issues early.

// Example Jest test for HIPAA compliance
describe('HIPAA Compliance Tests', () => {
  test('PHI is encrypted in transit', async () => {
    const response = await fetch('https://api.example.com/patient/123', {
      headers: { 'Authorization': 'Bearer test_token' }
    });
    
    // Check that the connection used TLS 1.2 or higher
    expect(response.connection.protocol).toMatch(/TLSv1\.[23]/);
  });
  
  test('Access logs are created for PHI access', async () => {
    await fetch('https://api.example.com/patient/123', {
      headers: { 'Authorization': 'Bearer test_token' }
    });
    
    // Check that access was logged
    const logs = await getAccessLogs();
    expect(logs).toContainEqual(expect.objectContaining({
      resource: '/patient/123',
      action: 'read',
      timestamp: expect.any(String),
      actor: expect.any(String)
    }));
  });
  
  test('Session expires after inactivity', async () => {
    // Get token
    const token = await getAuthToken();
    
    // Wait for token to expire
    await new Promise(resolve => setTimeout(resolve, 15 * 60 * 1000));
    
    // Try to use token after timeout
    const response = await fetch('https://api.example.com/patient/123', {
      headers: { 'Authorization': `Bearer ${token}` }
    });
    
    expect(response.status).toBe(401);
  });
});

Add tests to your CI/CD pipelines to prevent non-compliant code from reaching production, and to catch issues early in the development process.

Data catalogs and classification

Modern data governance platforms like Collibra (opens in a new tab), Alation (opens in a new tab), and Atlan (opens in a new tab) help track data lineage and enforce classification policies.

Data lineage

Data lineage is the process of tracking data from its origin to its destination. It helps organizations understand how data moves through their systems and ensures compliance with data handling policies.

Data catalogs are particularly useful in the modern AI-driven world, where data is often shared across multiple services and systems. By classifying data based on sensitivity and compliance requirements, you can ensure that only authorized services have access to sensitive data.

Aimed at data stewards and compliance officers, these platforms provide:

• Automated data discovery
• Data classification and tagging
• Data lineage tracking
• Compliance reporting

Compliance scanning in CI/CD

Tools like Snyk (opens in a new tab), Checkmarx (opens in a new tab), and SonarQube (opens in a new tab) can be configured to scan for compliance issues during the build process:

# Example GitLab CI configuration
stages:
  - test
  - compliance
  - deploy

compliance_scan:
  stage: compliance
  script:
    - checkmarx-scan --preset "PCI-DSS" --source "${CI_PROJECT_DIR}"
    - owasp-dependency-check --project "API" --scan "${CI_PROJECT_DIR}"
    - sonar-scanner -Dsonar.projectKey="${CI_PROJECT_NAME}" -Dsonar.qualitygate.wait=true
  only:
    - main
    - staging

This ensures that compliance issues are caught before code reaches production, significantly reducing remediation costs.

Implementation strategies

A successful compliance strategy requires a combination of technical controls, developer education, and continuous monitoring. You can use the following practical steps to get started.

Starting with a compliance matrix

Begin by mapping your compliance requirements to specific technical controls, like in the example table below.

Practicing continuous compliance

Rather than treating compliance as a point-in-time auditing activity, integrate it into your development process as follows:

1. Design phase: Include compliance requirements in acceptance criteria.
2. Development: Use prebuilt compliant patterns from internal libraries.
3. Testing: Run automated compliance tests and functional tests.
4. Deployment: Use infrastructure as code with compliance guardrails.
5. Monitoring: Set up alerts for compliance anomalies.

Investing in developer education

Create clear guidelines and training for developers:

• Maintain an internal knowledge base of compliance requirements.
• Develop design patterns and code examples for common compliance scenarios.
• Run regular workshops on regulatory changes and updates.
• Create developer-friendly checklists for different compliance frameworks.

Overcoming common challenges

Expect pushback from developers and legal teams. Use lists like the one below to prepare for the common objections you may encounter and plan how you will address them.

”Legal requirements are too vague for technical implementation”

Solution: Create a cross-functional team of legal and technical experts to translate requirements into specific technical controls. Document these translations in a shared repository.

”Compliance slows down development”

Solution: Build a library of pre-approved, compliant components that developers can reuse. Integrate compliance testing into your CI/CD pipeline to catch issues early.

”We can’t keep up with changing regulations”

Solution: Subscribe to regulatory update services and join industry groups. Implement a regular review cycle for compliance requirements and allocate time for updates in each sprint.

Who’s responsible?

By clearly defining roles and responsibilities, you can ensure that compliance is everyone’s job, not just the legal team’s:

Developer responsibilities

The development team’s responsibilities include:

• Implementing technical controls correctly
• Writing tests that verify compliance requirements
• Reporting potential compliance issues
• Understanding the “why” behind requirements

Legal team responsibilities

The legal team is responsible for:

• Translating regulations into clear requirements
• Providing guidance on edge cases
• Keeping up to date with regulatory changes
• Preparing for audits and documentation

DevSecOps team responsibilities

The responsibilities of the development, security, and operations team include:

• Building compliance tooling and automation
• Monitoring for compliance drift
• Creating reusable compliant patterns
• Training developers on compliance requirements

Resources and further reading

Here are some resources to help you discover more about API compliance:

Official documentation

• The NIST Cybersecurity Framework (opens in a new tab)
• The official text of the GDPR (opens in a new tab)
• The PCI DSS implementation guidelines (opens in a new tab)

Tools

• The Kong API Gateway (opens in a new tab), which you can use for centralized API governance.
• The Open Policy Agent (opens in a new tab), which you can use for policy as code.
• The HashiCorp Sentinel (opens in a new tab), which you can use for infrastructure policy enforcement.

Guides and best practices

• The OWASP API Security Top 10 (opens in a new tab)
• The Google Cloud Well-Architecture Framework’s guidelines for meeting compliance and privacy needs (opens in a new tab)
• The Security Pillar of the AWS Well-Architected Framework (opens in a new tab)

By adopting these practical approaches to API compliance, you can satisfy legal requirements without sacrificing development velocity. The key is to integrate compliance into your everyday workflows rather than treating it as a separate after-the-fact activity. This not only reduces your risks and costs but builds trust with your customers and partners.

Remember: The most effective compliance strategy is one that works with your development process, not against it.