API Security Monitoring: What to Log and Alert On

API security monitoring is the continuous review of software API traffic, identity, authorization decisions, schemas, and response behavior to spot attacks or risky changes in production. It uses structured logs, normal-behavior baselines, and alert rules. It complements security testing, which sends deliberate requests to find repeatable flaws before release.

If you want API security testing and monitoring in one place, Qodex runs security tests on every pull request and turns every alert into a check that stays.

Six things to monitor, with an illustrative starting rule for each. Tune every number to the route's baseline.

Every number there is illustrative, not an OWASP, CISA, NIST, or vendor benchmark. Replace them with your own measurements. The last column is our own mapping onto the OWASP API category names, since OWASP publishes no signal-to-category map.

What is API security monitoring?

Availability monitoring and security monitoring read the same traffic and ask different questions. Availability asks whether the API answers and how fast. Security asks who called, what they reached, whether the authorization decision was right, and whether the traffic still matches the contract.

One pair makes it concrete. Rising latency on GET /accounts/{id} belongs in availability monitoring. One subject reading accounts across two tenants is a security signal, and no latency chart will show it.

OWASP set the baseline in 2019. API10:2019 Insufficient Logging and Monitoring said an API is exposed when it produces no logs, or when the messages lack detail. It is exposed just as much when log integrity is not guaranteed, or when nobody continuously monitors the logs and the infrastructure. Its prevention list starts with logging failed authentication, denied access, and input-validation errors.

The 2023 list dropped that category. It did not stop mattering: every risk that stayed needs monitoring evidence before you can detect it. That last point is our reading, not something OWASP writes.

API security monitoring vs API security testing

StackHawk, comparing API discovery with API monitoring, calls monitoring reactive: it identifies issues only after they occur. The loop below is the correction. For how monitoring sits beside DAST, firewalls, and gateways, see API security posture management.

What should you log for API security?

An alert is only as good as the event behind it. A status code and a timestamp cannot say whether an authorization decision was right. The minimum useful event:

That list is our application of OWASP's requirement that logs identify the malicious actor, and of CISA's who, what, when, and where model. It is not a standard. NIST SP 800-92 covers the log-management lifecycle around it, and says of itself that it is not a step-by-step implementation guide.

Four things never belong in routine logs: raw tokens, API keys, passwords, and full payloads. Hash or redact stable identifiers so you can still group by caller, and capture payloads only through a controlled incident workflow. OWASP says to handle logs as sensitive data and guarantee their integrity. CISA says to protect them from unauthorized access or deletion, and retain them per policy and compliance needs.

The plumbing exists on the large clouds. AWS documents CloudWatch Logs for API Gateway calls, and CloudTrail for the request made, who made it, the source IP, and when. It also documents AWS Config with Amazon Simple Notification Service for noncompliance alerts. Azure API Management sends metrics and logs to Azure Monitor and on to Log Analytics, and supports metric and activity-log alert rules. Datadog says its API Endpoints view combines its SDK and protection product with API Gateway configuration and uploaded API definitions, and surfaces discovered schemas, sensitive-data types and authentication. None of that decides what to alert on. It gives you the events; the rules in this page are yours to set.

Discovery answers which endpoints exist, including the ones nobody wrote down. Monitoring watches the ones you know about. They meet at the inventory: discovery adds a route, monitoring gives it a baseline, and traffic with no record is an alert. Akamai says its API security platform builds that inventory from traffic, code, specifications and connected infrastructure, which is the same join done for you.

Six API security signals that deserve alerts

• Authentication failures and denials. Count 401 and 403 responses by hashed client, subject, route, and source IP, plus failures as a share of that client's requests. Start at 20 failures in 5 minutes with half its requests failing. A 401 is a missing or failed credential and a 403 is a valid identity denied access, and the query below counts both, as OWASP asks. Keep login, token refresh, and ordinary routes on separate baselines. Password resets and one broken integration make the same shape, so check the authentication path first.

• Object access, or BOLA. Per subject, count distinct object IDs, tenant mismatches, the authorization decision, and the status. Alert on any successful response for another tenant's object, whatever the count. For enumeration, start at 20 distinct peer objects in 10 minutes at three times that subject's 7-day baseline. Volume alone cannot prove broken object level authorization: without subject, tenant, object, and decision you are guessing. BOLA is one user reaching another user's object, not broken function-level authorization.

• Schema drift. Compare the normalized route, method, parameters, and response shape with the approved OpenAPI file. Alert on any new public method or field missing from it, and after five validation mismatches on one route in 10 minutes. Planned deployments change schemas too, so group by route and deployment version or every release pages you. Cloudflare documents Schema Profiles for the same job. OWASP API9 sets the version requirement.

• Unknown endpoints. Join the observed route, method, and host against the approved inventory, tracking first seen, last seen, authentication observed, and internet exposure. Page immediately for an internet-exposed unknown endpoint with no authentication observed. Everything else is lower severity, raised once per route and deployment. OWASP API9 names deprecated versions and debug endpoints. Traceable and Wallarm both claim continuous discovery of shadow APIs, and Wallarm says its detection covers REST, GraphQL, gRPC, SOAP and WebSocket traffic, which matters when your access log only understands plain HTTP routes. Start from an API inventory: without one, every route is unknown.

• Rate anomalies. Calculate requests per minute by route, client, subject, and source network, then compare with that route's rolling baseline rather than one global limit. A starting rule: the 5-minute rate above 100 per minute and above three times the 7-day median for that route and client. Keep a hard safety limit too, since resource exhaustion does not wait for a baseline. A burst can be abuse, scraping, credential stuffing, or a campaign that worked. Salt claims behavioral analysis for low-and-slow attacks.

• Response data volume. Track response bytes by route and status, with sensitive-data tags wherever you have classification. Alert above three times the route's 7-day 99th percentile, or when a sensitive-data class appears on a route whose contract forbids it. Exempt approved export and backup routes, with tighter identity checks instead. Microsoft's documentation for Defender for APIs claims detection of data exfiltration. OWASP API3 is the risk underneath.

How to set thresholds without drowning in alerts

An alert nobody trusts is worse than no alert. Six moves keep the volume down.

• Baseline per route and per client. One global number cannot fit a login endpoint and a nightly export.

• Combine a count with a ratio. A busy healthy client trips a count alone. It rarely trips both.

• Group repeats. Collapse by route and deployment, so one bad release is one alert, not one per request.

• Join the deployment version. A known release change then separates itself from an attack.

• Name an owner and an action. A rule with neither becomes a filter nobody reads.

• Test the rule before it pages anyone. Replay a known benign burst and a known attack trace.

Impart gives the example that makes this concrete: for one application 10,000 requests per second may be normal, and for another it means the API is under a denial-of-service attack. CISA arrives at the same place, recommending that you baseline normal behavior and alert on high-risk events such as failed logins.

Use two windows, not one. A five-minute window catches a burst and misses a slow crawl. A 7-day baseline catches the crawl and reacts too late to the burst. Salt aims its behavioral analysis at that second half, the low-and-slow attacks, which is why the BOLA and rate rules above pair a short count with a rolling baseline instead of choosing one window.

Runnable query: alert on authentication failures by client

This assumes a normalized table api_access_log with event_time, client_id_hash, route, and status_code. Run it every minute. A returned row is an alert candidate, not an incident.

WITH five_minutes AS (
  SELECT
    client_id_hash,
    route,
    COUNT(*) AS requests,
    COUNT(*) FILTER (WHERE status_code IN (401, 403)) AS auth_failures
  FROM api_access_log
  WHERE event_time >= CURRENT_TIMESTAMP - INTERVAL '5 minutes'
  GROUP BY client_id_hash, route
)
SELECT
  client_id_hash,
  route,
  requests,
  auth_failures,
  ROUND(auth_failures::numeric / NULLIF(requests, 0), 3) AS failure_ratio
FROM five_minutes
WHERE auth_failures >= 20
  AND auth_failures::numeric / NULLIF(requests, 0) >= 0.50
ORDER BY auth_failures DESC;

Each row is one client on one route over the last five minutes: how many requests it made, how many were 401 or 403, and what share failed. The 20-failure floor and the 0.50 ratio are illustrative, and get replaced once you have measured your normal clients. The ratio is what stops a busy healthy client from paging on count alone. Grouping by route gives one count per route, so a login route and an ordinary route stay separate. The query computes no historical baseline. It reads a fixed five-minute window, which is why both numbers need tuning rather than trust. It operationalizes OWASP's instruction to log failed authentication and denied access, and CISA's example of alerting on failed logins.

What to do when an API security alert fires

1. Validate the event. Is the rule right, and is this a known release or integration change? A rule that fires on every deploy is a broken rule, not an incident.

2. Correlate. Pull the trace ID and gather subject, tenant, object, authorization decision, and deployment version for the whole sequence, not the one request that crossed the threshold.

3. Check the identity. Which client, which key, active since when, and what that caller normally does here.

4. Contain. Revoke the token or key, block or rate-limit the client, and leave the hard cap in place.

5. Preserve evidence. Copy the relevant logs to protected storage before rotation removes them. OWASP asks for log integrity, and CISA says to protect logs from deletion.

6. Fix the control. The authorization check, the missing inventory record, or the schema that shipped unreviewed.

7. Add the regression test. The next section is that step.

Turn a production alert into a pull-request security check

Fixed bugs come back, and in production the monitor is usually what notices first. The moment to turn an alert into a permanent check is while the sequence that produced it is still in front of you, with the identity, the object and the decision attached. This loop is that conversion, step by step.

1. The monitor flags one client reading an unusual sequence of object IDs on GET /accounts/{id}.

2. The team correlates subject, tenant, object, authorization decision, trace ID, and deployment version, and confirms the reads crossed a tenant boundary.

3. The sequence is sanitized. Live tokens and personal data are replaced with fixed test identities and fixtures, and the setup data is pinned so the result repeats.

4. A test runner replays the sequence on the pull request and asserts that the second tenant's object returns the denial its contract defines, 403 in this example.

5. The same inputs and assertions run on every later pull request, which makes the check deterministic rather than a one-off reproduction.

6. After deployment, monitoring confirms the route, schema, and authorization behavior still match the tested contract.

Each half proves something the other cannot. The test proves the fix on a known build. The monitor proves it on real traffic. The script for the replayable check is on the posture page, so this page does not repeat it.

API security monitoring checklist

• An inventory joined to live traffic, so an unknown route is a question, not a surprise.

• Stable identity fields in every event: hashed client, subject, tenant, and authorization decision.

• Centralized logs, protected from unauthorized access and deletion, retained per policy.

• Baselines per route and per client, never one global threshold.

• Every rule tested against a benign burst and an attack trace before it pages anyone.

• A named responder for each rule, with the response action written down.

• The deployment version on every event, so drift and ordinary releases separate themselves.

• A path from a confirmed incident to a regression test that runs on later pull requests.

The per-endpoint version of these controls is the developer checklist. The testing half of the loop is API security testing.

Where Qodex fits

Testing finds it before release. Monitoring catches what only real traffic shows. A confirmed finding becomes a check that runs again. Qodex covers the first and third.

The alert-to-test loop above is where it meets this page. Qodex uses two real accounts in two organizations you control, an owner and a member, so the cross-tenant read that alert found is executed against your preview on every later pull request rather than inferred. Each finding carries the request and response that produced it, which is the same evidence the incident review needed. It is the recurring assessment between penetration tests, not a penetration test.

Log ingestion, production traffic and alerting stay with your monitoring stack. Run API security tests on pull requests.

Frequently Asked Questions

What does API security monitoring mean?

It is the continuous review of software API traffic for attacks and risky change: who called, what they reached, whether the authorization decision was right, and whether the response matched the contract. AppSentinels frames the same job as risk governance rather than observability.

What is the difference between API monitoring and API security monitoring?

API monitoring usually means availability and performance: is the endpoint up, how fast does it answer, how often does it error. API security monitoring reads the same traffic for identity, authorization decisions, schema conformance, and data behavior. Same pipeline, different questions.

Which API events should be logged for security?

Timestamp, request or trace ID, normalized route and method, hashed client identifier, authenticated subject and tenant, source IP, and status code. Then the authorization decision and reason, object or resource class, byte counts, schema version or validation result, sensitive-data classification, and deployment version. Never raw tokens, keys, passwords, or payloads.

Can API security monitoring detect BOLA attacks?

Only if the event carries subject, tenant, object, and the authorization decision. Volume alone cannot prove broken object level authorization, because a power user and an enumeration script look identical in a request count. With ownership context, a successful cross-tenant read is unambiguous.

How do you detect unknown or shadow API endpoints?

Join the route, method, and host you observe against the approved inventory, then track first seen, authentication observed, and internet exposure for anything that does not match. OWASP API9 covers the risk. Traceable and Wallarm both claim continuous discovery of rogue and shadow APIs.

How should teams set API security alert thresholds?

Measure the route and the client first, then set a count and a ratio together, so a busy healthy caller cannot page you on volume alone. Test every rule against a benign burst and an attack trace before it goes live. CISA recommends baselining normal behavior.

Does API security monitoring replace API security testing?

No. Testing proves a control on a known build before release, and covers only the cases you ran. Monitoring proves behavior on real traffic, and usually reports after the requests start. StackHawk calls monitoring reactive for that reason. Turn a confirmed production finding into a test.

How long should API security logs be retained?

There is no universal period. CISA says to retain logs in accordance with your own policies and compliance needs, and to protect them from unauthorized access or deletion while you hold them.