# API compliance: Practical approaches for modern development teams
Source: https://speakeasy.com/api-design/api-compliance

import { Callout } from "@/mdx/components";



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](https://web.archive.org/web/20250712030312/https://www.edpb.europa.eu/news/news/2024/dutch-sa-imposes-fine-290-million-euro-uber-because-transfers-drivers-data-us_en) 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:

| Framework | Access Control | Audit Logging | Data Minimization | Encryption | Breach Notification |
|-----------|----------------|---------------|-------------------|------------|---------------------|
| SOC 2     | ✓              | ✓             | –                 | ✓          | ✓                   |
| GDPR      | ✓              | ✓             | ✓                 | ✓          | ✓                   |
| PCI DSS   | ✓              | ✓             | –                 | ✓          | ✓                   |
| HIPAA     | ✓              | ✓             | ✓                 | ✓          | ✓                   |
| CCPA      | ✓              | ✓             | ✓                 | –          | ✓                   |

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](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) 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](https://docs.konghq.com/konnect/service-catalog/) 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.

```yaml