Akamai API Security — The Four Pillars

The unit of analysis: how an API is defined

Before any pillar can do its job, the platform needs a stable definition of “an API”.

This matters operationally. GET /v1/users/{id} and DELETE /v1/users/{id} on the same host are two distinct APIs with distinct baselines, distinct authentication expectations and distinct risk. It also means path templating is important: if identifiers are not collapsed into a parameter, /v1/users/1 and /v1/users/2 would explode into thousands of “APIs”.

API identity  =  METHOD  +  HOST                 +  PATH
                 GET        api.example.com:443     /v1/orders/{orderId}
                 POST       203.0.113.10:8443       /internal/payments
                 GET        [2001:db8::1]:443       /v2/profile

The four pillars at a glance

Pillar 1 — API Discovery

You cannot protect what you do not know exists. Discovery continuously builds and maintains the inventory: production APIs, shadow APIs (undocumented, deployed outside governance), rogue APIs (deliberately outside process), zombie/legacy APIs (deprecated but still answering), and third-party APIs your applications call.

Inputs to the inventory

• Observed traffic — the authoritative source. Every method/host/path seen is catalogued with its schema, data types and consumers.
• Recon — outside-in discovery of domains and subdomains you may not have registered as in-scope (below).
• Source code repositories — endpoint definitions found in code, before they ever receive traffic.
• Specifications — imported OpenAPI/Swagger definitions, compared against reality to surface drift.

Recon

The Recon module performs two core functions.

Discovery

Discovery uses passive discovery methods to identify root domains and subdomains linked to your organization. It sources data from public records, certificate transparency logs, and observed traffic, without sending any requests to your systems.

Detection

Detection performs non-intrusive scans of discovered domains to simulate attacker reconnaissance. It identifies public API patterns, exposed technologies, and sensitive data using approximately 70–150 requests per domain per month.

The six reconnaissance methods

These are the same steps an attacker performs. Recon runs them on your behalf so that the forgotten old-api host is found by you first.

Method 1 — Start with your top level domain

Example: information.com. This is your anchor point — everything else branches from here.

Method 2 — Domain registry lookup (WHOIS)

Every domain is registered with a registrar (GoDaddy, Namecheap, etc.).

Hit the registrar -> Find who OWNS information.com
                  -> Find what OTHER domains that same owner has registered
                  -> Now you have sister/brother domains too

So if the owner registered:

information.com
information-dev.com
info-internal.com
information-staging.com

You just expanded your target list without touching any server.

Method 3 — Certificate Authority scanning (SSL/TLS certificates)

This is the subdomain discovery technique. When companies get SSL certificates, they are logged in a public Certificate Transparency (CT) log — anyone can read it.

Go to CT logs -> Search for information.com certificates
              -> Find ALL subdomains that have ever had a certificate issued:

api.information.com
dev.information.com
staging.information.com
internal.information.com       <- things you forgot about
old-api.information.com        <- legacy forgotten endpoints
payments.information.com

This is completely passive — you haven't touched their servers yet, just read public records.

Method 4 — Active subdomain probing

Now you have a list of subdomains. Next step — which ones are actually alive?

Send a gentle GET request to each subdomain:

GET https://api.information.com          -> 200 OK  <- server is alive
GET https://dev.information.com          -> 200 OK  <- server is alive
GET https://old-api.information.com      -> 200 OK  <- forgotten server, still alive!
GET https://staging.information.com      -> timeout <- nothing here

Every server that responds gives you information.

Method 5 — Response analysis (IP + headers)

When a server responds, you immediately get a ton of information.

From the IP address:

Do a "dig" on the responding IP -> tells you:

Is it an on-premise server?     -> company runs own infrastructure
Is it Cloudflare IP range?      -> behind Cloudflare WAF
Is it Akamai IP range?          -> behind Akamai
Is it AWS IP range?             -> hosted on cloud
Is it Azure/GCP IP range?       -> cloud hosted

From the response headers:

Server: nginx/1.14.0            -> Nginx server, possibly old version
X-Powered-By: PHP/5.6           -> old PHP version, likely vulnerable
X-AspNet-Version: 4.0           -> .NET application
Via: 1.1 varnish                -> Varnish cache in front

Just from headers you now know the tech stack without logging in to anything.

Method 6 — Source code scanning

This is “one of the key things in our pocket right now”. What you look for in code:

• API endpoint definitions hardcoded in source
• Internal URLs and domain names
• API keys accidentally committed
• Comments mentioning internal systems
• Configuration files with environment details

Source code repository support

Supported repository platforms:

• Bitbucket Cloud — on-premises will be supported in an upcoming version.
• GitHub
• GitLab

Pillar 2 — Posture

Most security tools wait for something bad to happen. Posture finds the open doors before the attacker walks through them — automatically, continuously, without anyone having to manually run a scan or audit.

Engine 1 — Passive analysis

• Watches real traffic silently
• Learns what APIs exist
• Classifies what data flows through them
• Finds misconfigurations from observed behaviour

Engine 2 — Algorithm-based detection

• Runs security checks against what it discovers
• Maps issues to OWASP and compliance frameworks
• Flags things like exposed logs, bad auth config, insecure settings, and data policy violations

Engine 3 — Non-intrusive active testing

• Gently probes internet-facing APIs
• Approximately 10 GET requests per API per day
• Tests broken/malformed auth credentials
• Generates realistic requests based on real traffic
• Never modifies data (no POST/PUT/DELETE)

What all three together surface

Learning

Runtime detection is only as good as the model of “normal” behind it. The Learning phase builds that model per API.

What it's learning about each API

Authentication methods     -> does this API require auth? what kind?
Usage patterns             -> how is it typically called?
Data types                 -> what data flows through it?
Traffic characteristics:
   -> How many hits per day
   -> Error rates (how many 4xx/5xx)
   -> Authenticated vs unauthenticated ratio
   -> How much data is returned per call

The learning timeline

Read the “whichever is FIRST/LAST” column carefully — it is the difference between a fast and a conservative model. Authentication behaviour completes as soon as either 2 days pass or 5000 consumers are seen. Findings, specs and data types wait for both conditions — up to 7 days and 2000 consumers — so a low-traffic API can stay in learning well past the nominal 7 days.

What happens during learning

• Incidents → generated immediately, even during the learning period.
• Findings → only generated after the learning period completes.
• Schema → headers and body fields appear within minutes of first being seen.
• Authentication → reassessed every week based on the previous week's traffic.
• API samples → refresh within hours of any schema update.

Obfuscation of sensitive data

API Security must record enough of a request to investigate an incident, without becoming a secondary store of the very data it is protecting. It solves this with salted, hashed, trimmed values.

The three-step process

Step 1 - SALT
  Add unique random salt to the original value
  "123-45-6789" + "r4nD0m$alt!"  ->  "123-45-6789r4nD0m$alt!"

Step 2 - HASH
  Run SHA-256 on the salted value
  "123-45-6789r4nD0m$alt!"
     -> "a3f8c2d9e1b4f7a6c2d9e1b4f7a6c2d9e1b4f7a6c2d9e1b4f7a6c2d9e1b4f7a6"
     (64 character hash)

Step 3 - TRIM
  Cut the hash down to a shorter usable length
     -> "a3f8c2d9"   (shortened for storage/display)

The salt is what prevents rainbow table attacks: without it, an attacker with the hash of a known-format value such as an SSN or a card number could precompute every possibility and reverse it. The trimmed output is still stable, so the same input always produces the same short token — which is what lets an investigator correlate “this same account appeared in nine incidents” without ever seeing the account.

Mode 1 — Obfuscation by datatype (default)

You control WHAT gets obfuscated by data type

Default covers:
  -> All PCI data (payment info)
  -> Sensitive and forbidden datatypes
  -> All authentication headers

Most flexible - targeted obfuscation
Best for: most organizations

Mode 2 — Full body obfuscation

Obfuscates EVERYTHING in request/response body
+ query parameters

You still control headers/cookies/JWTs separately
Can add exceptions for specific fields you need visible

Tradeoff: harder to debug some incidents
Best for: high compliance environments

Mode 3 — Full body and headers obfuscation

Obfuscates EVERYTHING:
  -> Body
  -> Query parameters
  -> Headers
  -> Cookies
  -> JWTs

Can add exceptions for specific fields
Most restrictive mode available

Tradeoff: hardest to debug incidents
Best for: strictest regulatory environments (HIPAA, GDPR etc.)

Choosing a mode is a deliberate trade between investigative fidelity and data minimisation. Teams commonly start at Mode 1, then move regulated business units to Mode 2 or 3 with a short exception list for the non-sensitive correlation fields their responders actually rely on (request ID, tenant ID, API version).

Pillar 3 — Runtime detection and response

Runtime watches live traffic against everything Discovery and Learning established, and raises incidents when behaviour deviates. Because the platform knows each API's schema, expected data types, authentication posture and normal consumer behaviour, it can detect classes of abuse that a signature WAF cannot see.

Threat classes detected at runtime

Response options

• Alert and enrich into the SIEM/SOAR with the full request context (obfuscated as configured).
• Hand the offending client identifier to the edge for blocking, rate limiting, or a bot-management action.
• Feed the finding back to the owning team via the repository/ownership mapping from Discovery.

Pillar 4 — API testing

Testing shifts the same knowledge left into the development lifecycle. Instead of waiting for production traffic to reveal a broken authorisation check, tests are generated from the API's known specification and observed behaviour and run against pre-production environments and CI/CD pipelines.

• Generate test cases from real observed traffic, so they exercise realistic payloads rather than synthetic stubs.
• Cover authentication and authorisation logic explicitly — the flaws that scanners consistently miss because they are business-logic, not signature, problems.
• Fail the build on regression, and compare the deployed API against its declared specification to catch drift.

Putting the pillars together

1. Turn on Discovery and Recon first. Expect the inventory to be larger than the documented one. Triage by exposure (internet-facing), sensitivity (PII/PCI/PHI datatypes) and authentication posture.
2. Set the obfuscation mode before you onboard regulated traffic, not after.
3. Let Learning complete. Track which APIs are still learning and why — usually insufficient consumers.
4. Work the Posture backlog by framework. OWASP mapping gives an engineering-friendly ordering; compliance mapping gives an audit-friendly one.
5. Wire Runtime incidents into the SOC with an owner for each API from the repository mapping.
6. Push tests into CI/CD so the same class of finding cannot re-enter production.