Securing Internal vs Public APIs

In modern applications and microservices architectures, APIs are the backbone of communication. However, not all APIs are the same. Some are internal, used exclusively for service-to-service communication within an organization, while others are public, exposed to external clients, mobile apps, or third-party integrations.

Each type requires distinct security strategies to protect data, prevent abuse, and maintain service integrity.

What Are Internal APIs?

Internal APIs are private interfaces used for communication within an organization, primarily between microservices, backend systems, or internal applications. Unlike public APIs, they are not exposed to external users, but still require strong security to protect against insider threats, compromised services, or lateral attacks.

Examples of Internal APIs:

• Order Service → Inventory Service: Ensures stock availability is updated in real-time.
• Payment Service → Fraud Detection Service: Validates transactions internally.
• User Service → Analytics Service: Sends anonymized user data for reporting and insights.

Key Security Measures for Internal APIs:

1. Mutual TLS (mTLS)

• Authenticates both the calling and receiving services.
• Encrypts all internal traffic to maintain confidentiality.
• Prevents unauthorized services from accessing internal endpoints.

2. JWT Token Relay

• Forwards JWTs from the API Gateway to downstream services.
• Preserves user identity across multiple service calls.

3. Least-Privilege Access

• Services can only access endpoints they are authorized to use.
• Implements role-based or attribute-based access control for stricter security.

4. Segmentation & Network Policies

• Isolates internal services using VPCs, subnets, or Kubernetes network policies.
• Controls which services can communicate with each other, minimizing attack surface.

5. Monitoring & Auditing

• Logs all inter-service requests and responses for transparency.
• Detects anomalies, failed authentications, or suspicious behaviors in real time.

What Are Public APIs?

Public APIs are interfaces exposed to external clients, partners, or third-party applications. Since they are accessible over the internet, they are more vulnerable to attacks and require strong security measures to protect sensitive data, maintain service availability, and prevent abuse.

Examples of Public APIs:

• Payment gateway APIs for processing customer transactions.
• Mobile app APIs for retrieving user profiles or account information.
• SaaS platform APIs for integration with partner systems.

Essential Security Measures for Public APIs:

1. Authentication & Authorization

• Implement OAuth2 (Authorization Code Flow for users, Client Credentials Flow for applications).
• Validate API keys, JWTs, or tokens for each request.
• Apply role-based or scope-based access control to restrict endpoints appropriately.

2. Rate Limiting & Throttling

• Restrict the number of requests per client or IP address to prevent abuse.
• Protect against DoS/DDoS attacks and ensure fair API usage.

3. Traffic Encryption

• Enforce HTTPS/TLS for all communications.
• Optionally use mTLS for trusted partner connections.

4. Input Validation & Request Filtering

• Validate headers, query parameters, and request payloads.
• Block malformed, malicious, or unexpected requests to prevent injection attacks.

5. Monitoring & Logging

• Track API usage patterns, failed requests, and anomalies.
• Detect suspicious activities early and integrate with monitoring or alerting systems.

Key Differences Between Internal and Public APIs

Best Practices for Securing APIs

Securing APIs is critical to protect sensitive data, maintain service reliability, and prevent unauthorized access. The strategies differ for internal versus public APIs based on exposure and risk.

Internal APIs

• mTLS: Authenticate services and encrypt traffic.
• Token-Based Authentication: Use JWT or OAuth2 for identity propagation.
• Least-Privilege Access: Services access only what they need.
• Network Segmentation: Isolate services with VPCs or Kubernetes policies.
• Centralized Logging: Monitor requests and detect anomalies.

Public APIs

• Strong Authentication: OAuth2, API keys, or JWTs with scopes.
• Rate Limiting: Prevent abuse and DDoS attacks.
• HTTPS/TLS Encryption: Secure all traffic; optional mTLS for trusted partners.
• Input Validation: Block malformed or malicious requests.
• Monitoring & Alerts: Use WAFs, log requests, and track suspicious activity.

Practical Examples: Securing APIs with Spring Boot

1. Internal API (mTLS + JWT Relay)

Demonstrates encrypted and authenticated communication between microservices using mTLS while preserving user identity via JWT token relay.

Server Configuration (Spring Boot):

server:
  port: 8443
  ssl:
    key-store: service-keystore.p12
    key-store-password: changeit
    trust-store: truststore.p12
    trust-store-password: changeit

Client Configuration (WebClient):

@Bean
public WebClient webClient() throws Exception {
    SslContext sslContext = SslContextBuilder.forClient()
        .trustManager(new File("truststore.p12"))
        .keyManager(new File("client-keystore.p12"), "changeit")
        .build();

    HttpClient httpClient = HttpClient.create()
        .secure(sslSpec -> sslSpec.sslContext(sslContext));

    return WebClient.builder()
        .clientConnector(new ReactorClientHttpConnector(httpClient))
        .build();
}

Flow Example:

Client App → API Gateway → Service A → Service B → Service C

Highlights:

• All internal communication is encrypted and authenticated using mTLS.
• JWT token relay preserves user identity across multiple microservices.
• Ensures zero-trust internal communication.

2. Public API (JWT + Rate Limiting via Spring Cloud Gateway)

Shows how external client requests are secured with JWT authentication and protected against abuse with rate limiting and monitoring.

Spring Cloud Gateway Configuration:

spring:
  cloud:
    gateway:
      routes:
        - id: public-api
          uri: lb://public-service
          predicates:
            - Path=/api/public/**
          filters:
            - RequestRateLimiter:  # Limit requests per client
            - TokenRelay:          # Forward validated JWTs

• Validates incoming JWT tokens for authentication.
• Applies rate limiting to prevent abuse or DDoS attacks.
• Monitors requests and logs suspicious activity.
• Provides secure public access without exposing internal services.

Common Mistakes to Avoid

• Weak authentication on public APIs
• Exposing internal APIs directly to the internet
• Skipping encryption for sensitive internal traffic
• Ignoring rate limits and monitoring on public endpoints
• Hardcoding secrets, tokens, or API keys

Real-World Use Cases

Internal APIs:

• Microservices communication in Kubernetes clusters
• SaaS platforms with multi-tenant service communication

Public APIs:

• Mobile app APIs for external users
• Payment gateways and third-party integrations
• Cloud services exposing APIs to customers

Conclusion

Securing internal and public APIs requires different strategies:

• Internal APIs: Focus on authentication, mTLS, token relay, and zero-trust internal communication.
• Public APIs: Focus on strong authentication, rate limiting, HTTPS, request validation, and monitoring.

By implementing these practices, organizations can ensure secure, scalable, and resilient API ecosystems that protect sensitive data and maintain reliable service operations.