Web Service and API Secure by Design

A CISO's Playbook (2025 Edition)

𝗧𝗮𝗯𝗹𝗲 𝗼𝗳 𝗰𝗼𝗻𝘁𝗲𝗻𝘁:

• End-to-End TLS & HSTS Deployment

• OAuth 2.0 with PKCE & mTLS

• JWT Lifecycle Management & Signature Validation

• mTLS for Client Authentication

• Dynamic Rate Limiting & DDoS Protection

• Strict Input Validation & Output Encoding

• Fortified API Gateways with Integrated WAFs

• Secure Session Management & Cookie Hardening

• API Versioning & Secure Deprecation

• Exploiting Business Logic Flaws

• Securing Service-to-Service Communication

Introduction: The Blueprint for Digital Trust

In the sprawling metropolis of the digital age, APIs and web services are the invisible highways and bridges that connect continents of data. They are the lifeblood of modern applications, carrying everything from whispered secrets to financial fortunes. But for every architect designing these marvels, there is a saboteur plotting their downfall. Building these digital structures is no longer enough; we must build them to last, to withstand the relentless storms of cyber threats. This is the essence of being "Secure by Design."

This playbook is not a dusty tome of theoretical knowledge. It is a field manual for the modern digital architect, a guide for the CISO, the security engineer, and the developer on the front lines. We will move beyond the "what" and dive deep into the "how." We will tell stories of insecure architectures, not as cautionary tales, but as case studies from which we can learn. We will walk in the shoes of the attacker, understand their motives and methods (TTPs), and then pivot to the defender's mindset, arming ourselves with strategies, code, and tools to build resilient systems.

Forget the old paradigm of bolting security on as an afterthought. Today, we embed it into the very DNA of our services. We will explore nine critical domains of web service and API security, transforming abstract principles into actionable, real-world implementations. From encrypting data in transit to validating every request with zero-trust vigilance, this guide will equip you to build not just functional, but formidable digital experiences.

Let's begin.

---

Chapter 1: The Unseen Shield - End-to-End TLS Enforcement & HSTS Deployment

The trust a user places in your service begins with a single, silent handshake. This initial connection is a promise—a promise that their data is safe from prying eyes. When this promise is broken, the entire foundation of trust collapses. End-to-End Transport Layer Security (TLS) is this promise, and HTTP Strict Transport Security (HSTS) is the unbreakable vow that ensures it's never forgotten.

The Insecure Scenario: The Eavesdropper's Paradise

Imagine a bustling digital café, "The Open Port," where data flows as freely as coffee. The café offers free Wi-Fi, but it's an unsecured network. The service API, api.openport.com, is configured, but the developers overlooked a critical detail: while the login endpoint uses HTTPS, the rest of the API endpoints can be accessed via HTTP. They assume, "If the login is secure, the rest is fine."

A user connects to the café's Wi-Fi and logs into their account. The initial POST request to /login is encrypted. However, once authenticated, the application's frontend, built hastily, starts making subsequent API calls to http://api.openport.com/user/profile. The session cookie, now carrying a valid token, travels in plaintext across the café's network.

Attacker's Playbook: The Man-in-the-Middle (MitM)

An attacker, Mallory, sits in the same café, running a simple packet sniffer like Wireshark. She sees the unencrypted traffic to /user/profile.

• TTP 1: Passive Eavesdropping. Mallory filters for HTTP traffic and easily plucks the Authorization header or session cookie out of the air. She now has the user's session token and can impersonate them.

• TTP 2: SSL Stripping (Active Attack). A more sophisticated Mallory deploys a tool like sslstrip. When the user first tries to navigate to the service, their browser might attempt an HTTPS connection. Mallory's tool intercepts this, presents a fake certificate to the user (which they might click through), and establishes a plaintext connection with the user's browser while maintaining an encrypted one with the server. The user sees "HTTP" in the address bar but might not notice. Every piece of data they send is now visible to Mallory.

The Secure Architecture: The Fortress of Trust

A secure architecture leaves no room for ambiguity. Every single connection, without exception, must be encrypted.

1. End-to-End TLS: All API endpoints, from the load balancer to the application server and any internal microservices, communicate exclusively over TLS 1.2 or higher (preferably TLS 1.3). There are no "unencrypted backchannels."

2. HSTS Enforcement: The server sends the Strict-Transport-Security header with every HTTPS response. A typical policy looks like this: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

   • max-age=31536000: Tells the browser to enforce HTTPS for one year.

   • includeSubDomains: Applies the policy to all subdomains.

   • preload: Allows the domain to be submitted to browser-maintained HSTS preload lists, ensuring even the very first connection is secure.

3. HTTPS Redirects: Any accidental HTTP request is met with a permanent redirect (HTTP 301) to its HTTPS equivalent.

Defender's Code: Java Spring Security Implementation

In a Spring Boot application, enforcing these principles is straightforward.

SecurityConfig.java

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.security.web.header.writers.HstsHeaderWriter;

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        // 1. Require HTTPS for all requests
        http.requiresChannel(channel -> 
            channel.anyRequest().requiresSecure()
        );

        // 2. Enable and configure HSTS
        http.headers(headers -> 
            headers.httpStrictTransportSecurity(hsts -> 
                hsts.includeSubDomains(true)
                    .preload(true)
                    .maxAgeInSeconds(31536000)
            )
        );

        // ... other security configurations like authorization
        http.authorizeHttpRequests(authz -> authz
            .anyRequest().authenticated()
        );

        return http.build();
    }
}

This configuration ensures that Spring Security automatically redirects any HTTP traffic to HTTPS and adds the HSTS header to all responses.

Detection & Prevention

Semgrep Rule for Detecting Missing HSTS

A simple Semgrep rule can catch Spring Security configurations that fail to enable HSTS.

no-hsts-spring.yaml

rules:
  - id: spring-security-missing-hsts
    patterns:
      - pattern-not: $HTTP.headers(...).httpStrictTransportSecurity(...)
      - pattern-inside: |
          import org.springframework.security.config.annotation.web.builders.HttpSecurity;
          ...
          public SecurityFilterChain filterChain(HttpSecurity $HTTP, ...) {
            ...
          }
    message: "Spring Security configuration is missing HSTS configuration. HSTS is a critical defense against SSL stripping attacks. Please add '.headers().httpStrictTransportSecurity()' to your HttpSecurity chain."
    languages: [java]
    severity: WARNING

Claude Prompt for Detection

You can use a sophisticated AI prompt to analyze code for security best practices.

"Analyze the following Java Spring Security configuration file. Act as a senior security architect. Identify if the configuration correctly enforces End-to-End TLS and HSTS. Specifically, check for:

1. Redirection of all HTTP traffic to HTTPS.

2. The presence and correct configuration of the HSTS header, including includeSubDomains and preload directives.

3. Any potential misconfigurations that might allow unencrypted communication.
   Provide a summary of findings and recommendations for remediation if any issues are found."

Attack Flow Diagram

Here is a sequence diagram illustrating the SSL Stripping attack.

Secure Implementation Diagram

---

Chapter 2: The Gatekeeper's Dilemma - OAuth 2.0 with PKCE & mTLS