Lesson 27 — Microsoft Defender for APIs
APIs connect applications, identities, services and data. They are also direct entry points into business processes that may never appear in a traditional website interface.
Microsoft Defender for APIs provides visibility, security posture assessment and runtime threat detection for APIs published through Azure API Management.
This lesson follows the complete workflow: API inventory, onboarding, endpoint visibility, authentication review, posture findings, suspicious request investigation, containment and secure API design.
What you will learn
This lesson follows API security from discovery and onboarding through runtime alert investigation and remediation.
How Microsoft Defender for APIs works
↓
The Defender for APIs plan is enabled at subscription level
↓
Supported APIs are onboarded
↓
Defender builds visibility into API collections and endpoints
↓
Security posture and authentication findings are reviewed
↓
Runtime API activity is monitored
↓
Suspicious behaviour generates a Defender alert
↓
Agent Foskett reviews the endpoint, identity, source and request sequence
↓
The affected object, function or credential is identified
↓
Access is contained and the API control is corrected
↓
Validation confirms unauthorised requests are rejected
API security layers
| Layer | Purpose | Example |
|---|---|---|
| Inventory | Know which APIs and endpoints exist. | API Security dashboard. |
| Authentication | Confirm the caller’s identity. | Microsoft Entra JWT validation. |
| Authorisation | Limit each caller to permitted objects and functions. | Server-side ownership check. |
| Gateway controls | Apply consistent traffic and request policies. | API Management policy. |
| Posture | Identify exposure and configuration risks. | Defender recommendation. |
| Runtime detection | Detect active suspicious behaviour. | Defender for APIs alert. |
| Investigation | Reconstruct caller actions and impact. | Request, identity and application logs. |
Learning objectives
- Explain why APIs create a distinct security attack surface.
- Describe Microsoft Defender for APIs.
- Understand API Management onboarding and coverage.
- Review API inventory and endpoint information.
- Identify authentication and exposure risks.
- Recognise common API attacks.
- Investigate suspicious API activity.
- Contain abuse and improve API design.
What is an API?
An application programming interface allows software components to exchange data or invoke functions through defined requests and responses.
Why APIs are targeted
APIs often expose business data and privileged operations directly. An attacker may not need to compromise the website if the underlying API accepts an unauthorised request.
What is Microsoft Defender for APIs?
Microsoft Defender for APIs is a Microsoft Defender for Cloud plan that provides lifecycle protection, detection and response coverage for supported APIs published in Azure API Management.
Defender for APIs and Defender CSPM
Defender for APIs focuses on onboarded API Management APIs and runtime protection. Defender CSPM adds broader API discovery and posture visibility across supported Azure API Management, Function Apps and Logic Apps resources.
Azure API Management
Azure API Management publishes, secures and monitors APIs through a managed gateway. Defender for APIs integrates with supported cloud-hosted API Management gateways.
Plan enablement
The Defender for APIs plan is enabled at subscription level. Supported APIs must then be onboarded from relevant API Management instances.
Gradual onboarding
Onboard APIs carefully and monitor API Management capacity. Large-scale onboarding can add resource utilisation, so production environments should be observed during rollout.
API inventory
The API Security dashboard provides visibility into onboarded API collections, endpoints and API Management services.
Endpoint visibility
Endpoint information can include the operation name, URL path, HTTP method, recent observed traffic and authentication status.
Business-critical APIs
Prioritise APIs that expose payments, customer data, identity functions, administration, healthcare data, financial records or operational control.
Internet-facing APIs
Publicly reachable endpoints have a larger attack surface and should be reviewed for authentication, authorisation, encryption, input validation and rate controls.
Unauthenticated APIs
An endpoint without effective authentication may expose data or functions to any caller. Confirm whether anonymous access is intentional and safe.
Authentication
Authentication confirms who or what is calling the API. Common controls include subscription keys, client certificates, JWT validation and Microsoft Entra tokens.
Authorisation
Authorisation determines what an authenticated caller may access or perform. Successful authentication does not prove the caller is authorised for every object or function.
API keys
API keys can identify or meter clients, but they require secure storage, rotation, scope and monitoring. Do not treat a broadly shared key as strong user authentication.
OAuth and JWT
Validate token issuer, audience, signature, lifetime and required claims. A valid token may still represent the wrong user, tenant, application or permission scope.
Microsoft Entra integration
Microsoft Entra can provide application and delegated identities for APIs. Review app registrations, permissions, consent, service principals and token claims.
Broken Object Level Authorization
Broken Object Level Authorization occurs when an API accepts an object identifier but fails to confirm that the caller may access that specific object.
BOLA example
A signed-in customer changes /accounts/1042 to /accounts/1043. If the API returns another customer’s record, authentication succeeded but object-level authorisation failed.
Broken authentication
Weak token handling, predictable credentials, poor session controls or missing authentication can allow attackers to impersonate legitimate API clients.
Broken function-level authorisation
A normal user may discover and call an administrative endpoint when server-side role checks are missing or inconsistent.
Broken object property-level authorisation
An API may expose sensitive fields or allow protected properties to be changed even though the caller should only access part of the object.
Unrestricted resource consumption
High request rates, expensive queries, oversized payloads or repeated operations can consume compute, memory, bandwidth or third-party service capacity.
Injection
Untrusted API input can reach databases, operating systems, templates or downstream services. Validate, constrain and safely process every parameter and payload.
Server-side request forgery
An API that retrieves a caller-controlled URL may be abused to access internal services, metadata endpoints or restricted network locations.
Improper inventory management
Old versions, test endpoints, undocumented APIs and forgotten hosts can remain reachable after the business believes they have been retired.
Unsafe consumption of APIs
Applications must validate data received from third-party APIs rather than trusting it simply because it came from another service.
Shadow APIs
Shadow APIs are unknown to the security or governance team. They may be deployed outside approved inventory, ownership and monitoring processes.
Zombie APIs
Zombie APIs are obsolete or unused endpoints that remain active. Remove them or formally maintain them with current controls.
Sensitive data exposure
Responses should contain only the fields required by the caller. Avoid returning complete records when a narrow response is sufficient.
Rate limiting
Apply quotas, throttling and abuse controls appropriate to the API’s business function and expected client behaviour.
Schema validation
Validate request methods, paths, headers, content types, parameter ranges and payload schemas before processing data.
API Management policies
API Management policies can validate tokens, restrict callers, transform requests, apply quotas, inspect headers and standardise protective controls.
Runtime threat detection
Defender for APIs analyses monitored API activity to identify suspicious runtime behaviour and active threats.
Security recommendations
Use Defender recommendations to identify APIs that require onboarding or have posture weaknesses requiring remediation.
Security alerts
Alerts provide context about suspicious API activity, affected resources, request characteristics and recommended response actions.
API telemetry
Investigations may use API Management logs, gateway data, Defender alerts, Azure Activity Log, identity logs and application telemetry.
Initial triage
Confirm the API, endpoint, operation, caller, source IP, request time, response pattern and whether the activity matches expected application behaviour.
Request investigation
Review the HTTP method, path, query parameters, headers, token context, payload size, response code and sequence of object identifiers.
Identity investigation
Determine whether the caller used a user token, application identity, subscription key, client certificate or anonymous access.
Authorisation investigation
Test whether the caller should have accessed the requested object, property or function. Do not stop after confirming the token was valid.
Source investigation
Review source IP reputation, geography, hosting provider, request velocity and other API activity from the same source.
Scope investigation
Search for the same caller, token, key, IP address, user agent or object sequence across other endpoints and API versions.
Containment
- Disable exposed endpoints where necessary.
- Revoke compromised tokens, keys or certificates.
- Block malicious sources.
- Apply temporary rate limits.
- Correct authorisation checks.
- Restrict sensitive response fields.
- Preserve request evidence.
Remediation
Fix server-side access controls, validate every object request, strengthen token validation, remove obsolete APIs and retest the complete API workflow.
Validation
Confirm unauthorised object access is denied, legitimate clients still function, alerts have stopped and no alternate endpoint exposes the same data.
Agent Foskett investigation: “Nobody hacked the website…”
↓
The website loaded their account through an API
↓
The browser requested
/customers/2048↓
The customer changed the identifier to
/customers/2049↓
The API returned another customer’s record
↓
No password was guessed
↓
No malware was installed
↓
No authentication control was bypassed
↓
The API trusted the object identifier supplied by the caller
↓
Defender activity revealed repeated requests across sequential IDs
↓
Agent Foskett reviewed the token and confirmed it belonged to a valid customer
↓
The token was valid
↓
The authorisation decision was not
↓
Server-side ownership checks were added
↓
Responses were reduced to required fields
↓
Request monitoring and rate controls were strengthened
↓
Testing confirmed other customer records were denied
↓
Nobody hacked the website
↓
They simply asked the API for somebody else’s data
API investigation checklist
| Area | Question | Evidence |
|---|---|---|
| API | Which API, version and endpoint were targeted? | API inventory and Defender alert. |
| Request | What method, path, parameters and payload were used? | Gateway and application logs. |
| Identity | Which user, application, key or token made the request? | Token claims, key records and Entra logs. |
| Authorisation | Was the caller permitted to access that object or function? | Ownership, role and policy logic. |
| Source | Where did the activity originate? | IP address, geography and user agent. |
| Pattern | Were identifiers, endpoints or functions enumerated? | Request sequence and timing. |
| Exposure | What data or action became available? | Response codes, fields and downstream records. |
| Scope | Did the same weakness exist elsewhere? | Other versions, endpoints and APIs. |
| Recovery | Were credentials revoked and controls retested? | Change records and validation results. |
Key takeaways
- APIs expose business data and functions directly.
- Defender for APIs protects supported APIs published through Azure API Management.
- The plan provides API visibility, posture insights and runtime threat detection.
- API inventory should identify collections, endpoints, methods and recent traffic.
- Authentication and authorisation are separate security decisions.
- Broken Object Level Authorization can expose another user’s data through a simple identifier change.
- Server-side controls must validate access to every requested object and function.
- API Management policies can standardise token, quota and request controls.
- Investigations should correlate Defender alerts, API requests, identities and application telemetry.
- Retired, undocumented and unauthenticated APIs require immediate attention.
What Agent Foskett checked
- Defender alert
- API collection
- Endpoint
- HTTP method
- Object identifier
- Token claims
- Caller identity
- Source IP
- Response code
- Returned fields
- Request sequence
- Other API versions
Best practices
- Maintain a complete API inventory.
- Onboard supported critical APIs.
- Require strong authentication.
- Validate object-level authorisation.
- Apply least privilege.
- Validate JWT claims.
- Use quotas and rate limits.
- Remove obsolete APIs.
- Limit response fields.
- Investigate enumeration patterns.
Related Agent Foskett resources
Continue learning
What is Microsoft Defender for APIs?
Microsoft Defender for APIs is a Microsoft Defender for Cloud plan that provides visibility, security posture assessment and runtime threat detection for supported APIs published through Azure API Management.
Microsoft Defender for APIs Lesson
This Agent Foskett lesson explains API inventory, Azure API Management onboarding, authentication, authorisation, API posture, runtime alerts, Broken Object Level Authorization and API investigation workflows.
