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

Feature	Internal APIs	Public APIs
Access	Trusted internal services within the organization	External clients, partners, or third-party users
Security Focus	Authentication and authorization between services	Strong access control, rate limiting, and active monitoring
Exposure	Private network or cloud infrastructure	Internet-facing endpoints accessible to anyone
Encryption	Optional TLS/mTLS within internal network	Mandatory HTTPS/TLS for all external traffic
Rate Limiting	Moderate; based on service load and trust	Strict limits to prevent abuse, DoS attacks, and overloading
Logging & Auditing	Focus on internal compliance and troubleshooting	Regulatory reporting, monitoring for suspicious activity, and external visibility

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.