api-security-design

Name: api-security-design
Author: vinayaklatthe

161stars34forks

How to install api-security-design?

vinayaklatthe/microsoft-security-skills/api-security-design

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill api-security-design

Installs into the current project.

Summary

Guidance for designing secure APIs on Azure - authentication, authorization, gateway controls, input validation, rate limiting, secret management, and runtime threat detection - aligned to OWASP API Security Top 10 and Azure API Management. WHEN: API security design, secure API,

Files · 1

View on GitHub

SKILL.md

1	# API Security Design
2
3	Secure API design protects backend services and data from abuse and the **OWASP API Security
4	Top 10** risks - broken object-level authorization (BOLA), broken authentication, broken
5	function-level authorization (BFLA), unrestricted resource consumption, server-side request
6	forgery, and more. On Azure, Azure API Management (APIM) is the primary policy enforcement
7	point, paired with WAF, Entra ID, Key Vault, and Defender for APIs.
8
9	## When to use
10	Designing or reviewing the security of APIs - especially external-facing, partner-facing, or
11	sensitive-data APIs - before they go live or as part of a recurring design review.
12
13	Do not use this skill for:
14	- General application or web app security (use `security-architecture`, `threat-modelling`)
15	- API runtime detection and posture only (use `defender-for-apis`)
16	- Front-end / SPA design (use web app security guidance)
17
18	## Pick the right control per OWASP API risk
19
20	\| OWASP API Top 10 risk \| Primary control \| Where it lives \|
21	\|---\|---\|---\|
22	\| API1 - BOLA (object-level auth) \| Per-object authorization check \| Backend code (gateway cannot fully cover) \|
23	\| API2 - Broken authentication \| OAuth 2.0 / OIDC with Entra ID, `validate-jwt` \| Gateway + Entra \|
24	\| API3 - Broken object property auth \| Schema validation + response filtering \| Backend + gateway \|
25	\| API4 - Unrestricted resource consumption \| Rate limit, quota, payload size, timeout \| Gateway (APIM) \|
26	\| API5 - BFLA (function-level auth) \| Role/scope check on each operation \| Backend code \|
27	\| API6 - Unrestricted access to sensitive flows \| Step-up auth, anti-abuse rules \| Entra + gateway \|
28	\| API7 - SSRF \| Outbound URL allow-list + egress controls \| Backend + network \|
29	\| API8 - Security misconfiguration \| IaC + APIM policy templates \| DevOps + gateway \|
30	\| API9 - Improper inventory management \| API catalog + lifecycle in APIM \| APIM + governance \|
31	\| API10 - Unsafe consumption of third-party APIs \| Validate upstream responses, timeouts \| Backend \|
32
33	> Rule of thumb: BOLA and BFLA are the top two API risks and **cannot be fully fixed
34	> at the gateway** - the backend must enforce per-object and per-function authorization. The
35	> gateway is necessary but not sufficient.
36
37	## Approach
38
39	1. Authentication at the gateway with Entra ID - Require OAuth 2.0 / OpenID Connect via
40	Microsoft Entra ID; validate JWTs at APIM with the `validate-jwt` policy (issuer,
41	audience, signing key, expiration, required claims). Avoid static API keys as the only
42	control - rotate them aggressively if used at all.
43	*Verify: a request with an invalid or expired JWT is rejected at the gateway; logs show the
44	rejection reason.*
45	2. Authorization in the backend - Enforce least-privilege scopes/roles in the JWT, then
46	check object-level and function-level authorization in the backend on every call.
47	The gateway sees the caller; only the backend knows whether the caller owns the object.
48	*Verify: a test JWT for user A returns 403 when requesting user B's data, even though the
49	gateway lets the call through.*
50	3. Apply gateway protections (APIM) - Configure: rate-limit and quota policies per
51	subscription/IP/identity, IP filtering for allow-lists, request and response validation
52	against the OpenAPI schema, payload size limits, timeouts, and CORS scoped to known
53	origins.
54	*Verify: a request exceeding the rate limit returns 429; an oversized payload is rejected;
55	a request not matching the OpenAPI schema is rejected.*
56	4. Transport and secrets - Enforce TLS 1.2+ on every endpoint, use mTLS to backends
57	where threat model requires it, and store all secrets (backend credentials, signing keys)
58	in Azure Key Vault referenced via APIM named values with a managed identity. No
59	secrets in policy XML, no secrets in code.
60	*Verify: no secret literal appears in APIM policies or source repo; APIM uses managed
61	identity to fetch Key Vault references at runtime.*
62	5. Exposure and network controls - Front public APIs with WAF (Application Gateway or
63	Azure Front Door) for L7 protection (OWASP Core Rule Set), and use Private Endpoints to
64	keep backends off the public internet. Internal APIs should not have a p

People who liked this also viewed

6 picks

Type

api-security-design

161stars34forks

View on GitHub

How to install api-security-design?

vinayaklatthe/microsoft-security-skills/api-security-design

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill api-security-design

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# API Security Design
2
3	Secure API design protects backend services and data from abuse and the **OWASP API Security
4	Top 10** risks - broken object-level authorization (BOLA), broken authentication, broken
5	function-level authorization (BFLA), unrestricted resource consumption, server-side request
6	forgery, and more. On Azure, Azure API Management (APIM) is the primary policy enforcement
7	point, paired with WAF, Entra ID, Key Vault, and Defender for APIs.
8
9	## When to use
10	Designing or reviewing the security of APIs - especially external-facing, partner-facing, or
11	sensitive-data APIs - before they go live or as part of a recurring design review.
12
13	Do not use this skill for:
14	- General application or web app security (use `security-architecture`, `threat-modelling`)
15	- API runtime detection and posture only (use `defender-for-apis`)
16	- Front-end / SPA design (use web app security guidance)
17
18	## Pick the right control per OWASP API risk
19
20	\| OWASP API Top 10 risk \| Primary control \| Where it lives \|
21	\|---\|---\|---\|
22	\| API1 - BOLA (object-level auth) \| Per-object authorization check \| Backend code (gateway cannot fully cover) \|
23	\| API2 - Broken authentication \| OAuth 2.0 / OIDC with Entra ID, `validate-jwt` \| Gateway + Entra \|
24	\| API3 - Broken object property auth \| Schema validation + response filtering \| Backend + gateway \|
25	\| API4 - Unrestricted resource consumption \| Rate limit, quota, payload size, timeout \| Gateway (APIM) \|
26	\| API5 - BFLA (function-level auth) \| Role/scope check on each operation \| Backend code \|
27	\| API6 - Unrestricted access to sensitive flows \| Step-up auth, anti-abuse rules \| Entra + gateway \|
28	\| API7 - SSRF \| Outbound URL allow-list + egress controls \| Backend + network \|
29	\| API8 - Security misconfiguration \| IaC + APIM policy templates \| DevOps + gateway \|
30	\| API9 - Improper inventory management \| API catalog + lifecycle in APIM \| APIM + governance \|
31	\| API10 - Unsafe consumption of third-party APIs \| Validate upstream responses, timeouts \| Backend \|
32
33	> Rule of thumb: BOLA and BFLA are the top two API risks and **cannot be fully fixed
34	> at the gateway** - the backend must enforce per-object and per-function authorization. The
35	> gateway is necessary but not sufficient.
36
37	## Approach
38
39	1. Authentication at the gateway with Entra ID - Require OAuth 2.0 / OpenID Connect via
40	Microsoft Entra ID; validate JWTs at APIM with the `validate-jwt` policy (issuer,
41	audience, signing key, expiration, required claims). Avoid static API keys as the only
42	control - rotate them aggressively if used at all.
43	*Verify: a request with an invalid or expired JWT is rejected at the gateway; logs show the
44	rejection reason.*
45	2. Authorization in the backend - Enforce least-privilege scopes/roles in the JWT, then
46	check object-level and function-level authorization in the backend on every call.
47	The gateway sees the caller; only the backend knows whether the caller owns the object.
48	*Verify: a test JWT for user A returns 403 when requesting user B's data, even though the
49	gateway lets the call through.*
50	3. Apply gateway protections (APIM) - Configure: rate-limit and quota policies per
51	subscription/IP/identity, IP filtering for allow-lists, request and response validation
52	against the OpenAPI schema, payload size limits, timeouts, and CORS scoped to known
53	origins.
54	*Verify: a request exceeding the rate limit returns 429; an oversized payload is rejected;
55	a request not matching the OpenAPI schema is rejected.*
56	4. Transport and secrets - Enforce TLS 1.2+ on every endpoint, use mTLS to backends
57	where threat model requires it, and store all secrets (backend credentials, signing keys)
58	in Azure Key Vault referenced via APIM named values with a managed identity. No
59	secrets in policy XML, no secrets in code.
60	*Verify: no secret literal appears in APIM policies or source repo; APIM uses managed
61	identity to fetch Key Vault references at runtime.*
62	5. Exposure and network controls - Front public APIs with WAF (Application Gateway or
63	Azure Front Door) for L7 protection (OWASP Core Rule Set), and use Private Endpoints to
64	keep backends off the public internet. Internal APIs should not have a p

People who liked this also viewed

6 picks

Type