API
A fictional contract allowing approved applications or services to request specific data or actions from another service.
High School AdvancedModule A10Lesson A10.5API Defense
A10.5 API Security Concepts
Learn how professional defenders reason about APIs as explicit contracts between fictional users, applications, services, and suppliers. Review caller identity, authorization, object ownership, request schemas, response minimization, safe errors, versioning, dependencies, resource protection, monitoring, privacy, and resilience without enumeration, fuzzing, exploit payloads, unauthorized requests, or real API testing.
Lesson Progress
API Defense Control Design
High School Advanced • A10: Advanced Web Security Defense • Lesson 5 of 10
50% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
An API Is a Contract, Not an Open Door
Northbridge's fictional Application Service B can call Case Status API for an approved case workflow. That does not mean the service automatically receives every case, field, administrative action, or API in the environment.
Professional defenders ask who the caller is, why it needs the API, which exact resource and action are required, what ownership applies, what request structure is valid, which response fields are necessary, how dependencies fail, and which evidence proves the contract still matches current business need.
Weak API thinking
“The service is internal and authenticated, so it can use the API.”
Defender API thinking
“Identity is only the start. Purpose, authorization, object ownership, schemas, minimized responses, safe errors, monitoring, dependencies, and lifecycle ownership still matter.”
Learning Objectives
Five Objectives for A10.5
Objective 1
Explain how secure API design connects caller identity, authorization, object ownership, request contracts, resource actions, response minimization, safe errors, dependencies, versioning, monitoring, and resilience.
Objective 2
Evaluate fictional API access using caller purpose, service identity, least privilege, resource sensitivity, action scope, object ownership, business context, source health, and decision ownership.
Objective 3
Design fictional API contracts with explicit request schemas, bounded responses, safe error behavior, version ownership, privacy expectations, and resource-protection concepts without offensive testing.
Objective 4
Use fictional evidence to identify excessive API privilege, ambiguous service-identity ownership, weak object-scope assumptions, over-broad responses, hidden dependency risk, monitoring gaps, and incomplete version governance.
Objective 5
Create a professional fictional API Defense Review package containing callers, resources, actions, schemas, ownership rules, response limits, errors, dependencies, monitoring questions, resilience decisions, remediation owners, and public-safe documentation.
Why It Matters
APIs Concentrate Trust, Data, and Business Actions
APIs connect browser-facing applications to identity, data, reporting, administration, suppliers, monitoring, and recovery. If API contracts are vague, callers can accumulate excessive privilege, receive unnecessary data, depend on undocumented behavior, or remain on retired versions indefinitely.
Strong API design makes those assumptions explicit through callers, owners, least-privilege decisions, schemas, minimized responses, safe errors, version plans, monitoring questions, and resilience rules.
Advanced Vocabulary
API Defense-Control Language
Caller
The fictional user, application, service, or service identity requesting an API action.
Service identity
A fictional non-human identity representing an approved application or service under explicit purpose and privilege.
Resource
The fictional object or capability exposed by an API, such as case status, report summary, profile preference, recovery state, or configuration.
API action
The bounded fictional operation requested on a resource, such as read status, update an approved field, generate a report, or perform a privileged configuration change.
Request schema
The fictional contract describing required and optional fields, types, allowed values, sizes, relationships, and business meaning for a request.
Response schema
The fictional contract defining which approved fields a caller receives and their meaning, sensitivity, and optionality.
Object ownership
The fictional relationship determining whether a caller is legitimately associated with the exact resource requested.
Least privilege
Giving a fictional caller only the API resources and actions required for its approved purpose.
Response minimization
Returning only the fictional fields the caller needs instead of every field stored by the service.
Safe API error
A fictional failure response that provides useful handling information without exposing unnecessary internal, secret, private, or security-sensitive detail.
Versioning
A fictional process for managing API contract changes, compatibility, migration, validation, ownership, and retirement.
Dependency
A fictional internal or supplier service an API relies on for identity, data, monitoring, reporting, recovery, or another business function.
Resource-protection concept
A defensive design defining normal request size, response size, workload, concurrency, expensive-operation, and degraded-mode expectations without bypass guidance.
Idempotency concept
A fictional design property that helps repeated approved requests produce predictable business effects when the workflow requires it.
Observability
The ability of fictional owners and defenders to understand API health, access decisions, errors, version use, dependency state, and important changes through approved monitoring.
Core Framework
Twelve API Defense-Control Principles
1
Start with caller purpose
Every fictional API caller should have an explicit business reason, owner, environment, and resource/action need.
Defender question
Why does this caller need this exact API capability?
2
Authenticate the caller
The API needs bounded identity context for the fictional caller before protected decisions can be made.
Defender question
Which approved identity represents this caller?
3
Authorize every protected action
Successful caller identity does not automatically grant every API resource or action.
Defender question
Which explicit policy allows this caller to perform this action on this resource?
4
Check object ownership
A caller may be allowed to access some fictional objects but not unrelated objects of the same type.
Defender question
What relationship connects this caller to this exact resource?
5
Define the request contract
Every request should have an expected structure, type, allowed values, size, relationships, and business meaning.
Defender question
What does a valid fictional request look like before the API relies on it?
6
Minimize the response
The API should return only the fields needed for the approved caller purpose.
Defender question
Which response fields are actually necessary?
7
Design safe errors
Legitimate callers need predictable failure categories without unnecessary internal, secret, or private detail.
Defender question
What must the caller know to handle the failure safely?
8
Protect resources proportionally
API design should define normal request sizes, work limits, concurrency, and business-volume assumptions without teaching bypass methods.
Defender question
What normal workload should this API support while preserving availability?
9
Govern versions
Contract changes can alter data, authorization, caller behavior, privacy, monitoring, dependencies, and support.
Defender question
Who owns this version change, migration, validation, and retirement?
10
Treat dependencies as governed trust
Internal and supplier APIs need purpose, owner, expected behavior, monitoring, failure handling, and re-review.
Defender question
What happens when this dependency becomes unavailable or changes behavior?
11
Monitor defender questions
API monitoring should focus on access decisions, errors, health, sensitive actions, version changes, source health, and business-impact signals.
Defender question
Which API event helps an owner or defender make a decision?
12
Record Unknowns
Incomplete ownership, service identity, version, dependency, or policy assumptions should become owned Unknowns rather than guessed conclusions.
Defender question
Which missing fact prevents a defensible API decision?
Professional Workflow
The Ten-Step API Defense Review Workflow
1. Define the API purpose
Identify the fictional business service, caller classes, owners, resources, actions, sensitive data, availability goals, privacy goals, and exclusions.
Output
API review charter.
2. Define callers and identities
List fictional users, application components, service identities, administrators, recovery roles, and suppliers with approved purposes.
Output
Caller and service-identity register.
3. Define resources and actions
Map exact fictional resources and bounded actions instead of using broad API-access permissions.
Output
Resource/action matrix.
4. Define authorization and ownership
Connect role, service purpose, object ownership, business scope, administrative context, and least privilege.
Output
API authorization matrix.
5. Define request schemas
Document required/optional fields, types, allowed values, sizes, relationships, normalization, and business validation.
Output
Request contracts.
6. Define response schemas
Return only approved fields and avoid unnecessary sensitive, administrative, identity, or internal data.
Output
Minimized response contracts.
7. Define errors and resource protection
Create safe failure categories and normal workload/resource expectations without exposing unnecessary detail or bypass guidance.
Output
Error and resilience policy.
8. Review dependencies and versions
Map internal/supplier dependencies, owner expectations, failure states, compatibility, migration, and retirement.
Output
Dependency and version register.
9. Design monitoring
Tie access decisions, errors, health, sensitive actions, configuration, versions, source health, and dependency events to defender questions.
Output
API monitoring plan.
10. Validate and improve
Use safe fictional contract cases, owner review, expected allow/deny decisions, monitoring, and resilience scenarios without unauthorized testing.
Output
API Defense Review package.
Fake Dashboard
Fictional Northbridge API Defense Dashboard
A10.5 — API contract review
API contracts
9
Case, reporting, preferences, admin, recovery, supplier, version, and new-caller examples
Decision cases
8
Allow, deny, temporary allow, supplier-scope, and deprecated-version decisions
Review dimensions
8
Caller, purpose, resource/action, ownership, schema, response, dependency, version/monitoring
Primary rule
Explicit contract
Identity alone never replaces authorization, ownership, schema, and response rules
API Contracts
Nine Fictional API Contracts and Changes
Case Status API
Provide approved fictional case status to Application Service B.
Expected contract
Service Identity P; bounded case reference; read-status action; authorized workflow ownership; minimized status response.
Avoid
Do not treat internal service identity as permission for every case or return full case content by default.
Review focus
Caller purpose, case ownership, response fields, errors, dependencies, monitoring, recertification.
Case Update API
Allow approved case participants to update selected workflow fields.
Expected contract
Application Service B on behalf of an authenticated user; authorized case; approved action and field contract.
Avoid
Do not let schema validity replace authorization or allow unrestricted field changes.
Review focus
User/session context, case ownership, field authorization, business rule, change audit, safe response.
Reporting API
Generate approved aggregate fictional reports.
Expected contract
Reporting Service Q; approved report category, date range, team scope, and aggregate response.
Avoid
Do not expose raw case content or unrelated team data because the caller is a reporting service.
Review focus
Team authorization, aggregation, export purpose, privacy, response size, version, monitoring.
Profile Preferences API
Allow users to manage approved personal portal preferences.
Expected contract
Current authenticated user; own profile; approved preference actions and response fields.
Avoid
Do not expose unrelated identity/admin data or permit edits to another user's resource.
Review focus
Object ownership, sensitive-action state, schema, response minimization, audit.
Administrative Configuration API
Support privileged application configuration.
Expected contract
Application Administrator; privileged session; approved change; bounded setting/action; monitored result.
Avoid
Do not combine ordinary user access with privileged configuration or assume admins own all business data.
Review focus
Least privilege, change approval, rollback, monitoring, dependency health, session state.
Recovery Validation API
Support staged fictional recovery checks.
Expected contract
Recovery Service R or approved Recovery Operator; active recovery event; time-bound access; validation-only response.
Avoid
Do not let recovery access become permanent production administration.
Review focus
Event scope, expiration, dependencies, monitoring, rollback, owner approval.
Supplier Status API
Exchange one purpose-limited fictional service status with Supplier S.
Expected contract
Approved supplier identity; service identifier/status only; contracted business purpose.
Avoid
Do not expose case content, user profiles, admin configuration, or reporting data.
Review focus
Contract scope, minimization, retention, monitoring, outage behavior, re-review.
API Version V2
Provide the current approved contract generation for supported callers.
Expected contract
Documented caller migration, compatible schemas, updated authorization/privacy review, monitoring, owner and retirement plan for V1.
Avoid
Do not leave deprecated versions indefinitely without owner-approved transition.
Review focus
Migration state, version use, changed fields/actions, dependencies, privacy, retirement.
Mobile Preferences Caller
Proposed fictional mobile client for Profile Preferences API.
Expected contract
New caller identity, business purpose, own-profile scope, minimized response, version/support ownership.
Avoid
Do not inherit browser-client privileges automatically.
Review focus
Caller identity, authorization, schema, response, privacy, monitoring, support, version compatibility.
Fake SOC Alert
Fictional API Scope Review Warning
Source: A10.5 API defense board • Time: Northbridge API review 15:25
Supplier Integration S is contracted only for a fictional service-status workflow, but a proposed change would allow it to request full support-case records because broader access might simplify future troubleshooting.
Defensive recommendation: Hold the change. Keep Supplier S limited to the approved purpose, return only minimized fields, require a new owner-approved business case for expanded scope, review privacy and retention, update monitoring, and document failure and rollback before release.
Contract Dimensions
Eight Inputs to a Defensible API Decision
Caller identity
Who or what is making the fictional request?
Strong evidence
Current user or service identity, owner, environment, valid session/service context.
Weak assumption
Internal caller means trusted caller.
Business purpose
Why is this API request needed?
Strong evidence
Documented workflow, owner, and approved service purpose.
Weak assumption
The caller may need it someday.
Resource and action
What exact object/capability and operation are requested?
Strong evidence
Bounded resource plus read, update, report, configure, or validate action.
Weak assumption
API access means access to every action.
Object ownership
What relationship connects the caller to this exact resource?
Strong evidence
Case assignment, own profile, approved team scope, service contract, recovery event.
Weak assumption
Same role means all objects.
Request schema
Does the request meet its expected contract?
Strong evidence
Required fields, types, values, sizes, relationships, and business validation.
Weak assumption
Any parsable request is acceptable.
Response scope
Which fields does the caller actually need?
Strong evidence
Minimized response tied to business purpose and authorization.
Weak assumption
Return everything and let the caller ignore extra fields.
Dependency state
Are identity, data, supplier, monitoring, and recovery dependencies healthy enough for this decision?
Strong evidence
Current source health and approved degraded-mode rules.
Weak assumption
Dependency failure never changes security decisions.
Version and monitoring
Which contract version and evidence sources apply?
Strong evidence
Supported version, migration state, source health, owner, and monitoring coverage.
Weak assumption
Older versions and blind intervals are equivalent to current healthy state.
Fake Log Panel
Fictional API Review Log
training-log-viewer.log
15:00 | API | CaseStatus | caller=ServiceIdentity-P | action=read-status | result=Allow 15:03 | OWNERSHIP | case=C-104 | workflow=approved | decision=Allow 15:05 | REPORT | caller=Reporting-Q | scope=TeamBlue | result=Allow 15:06 | REPORT | caller=Reporting-Q | scope=TeamGold | result=Deny 15:10 | ADMIN | caller=AppAdmin | privileged_session=true | change_approval=true 15:15 | RECOVERY | caller=Recovery-R | access=time-bound | result=Allow 15:20 | VERSION | V1 | status=Deprecated | migration_owner=API-Owner 15:25 | SUPPLIER | request=full-case-data | contracted_scope=status-only | approval=Hold
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Analyze the Valid Request for the Wrong Team
The request schema is valid.
The caller identity is known.
Team Gold scope is not approved for this caller.
Validation and authorization are separate decisions.
Reporting Service Q sends a structurally valid report request for Team Gold while the caller is approved only for Team Blue. What is strongest?
Safe API Decision Cases
Eight Fictional API Decisions
API-CASE-01Allow
Application Service B requests status for an authorized fictional case.
Subject
Service Identity P
Resource
Case Status API / Case C-104
Action
Read status
Context
Approved workflow and object ownership.
Reason
Caller purpose, action, and object scope align.
Monitoring
Record caller, resource class, decision, health, and source state.
API-CASE-02Deny
The same service requests a case outside its approved workflow scope.
Subject
Service Identity P
Resource
Case Status API / unrelated case
Action
Read status
Context
Schema valid; ownership/business scope does not match.
Reason
Valid request shape does not replace authorization.
Monitoring
Record denial without assuming malicious intent.
API-CASE-03Allow
Reporting Service Q requests Team Blue aggregate metrics.
Subject
Reporting Service Q
Resource
Reporting API / Team Blue
Action
Generate report
Context
Category/date valid and team scope approved.
Reason
Purpose and authorization align.
Monitoring
Record report type, scope, result, size, and health metadata.
API-CASE-04Deny
Reporting Service Q requests Team Gold metrics without approved scope.
Subject
Reporting Service Q
Resource
Reporting API / Team Gold
Action
Generate report
Context
Technically valid schema; authorization mismatch.
Reason
Team scope is an independent authorization decision.
Monitoring
Record policy decision and ownership mismatch.
API-CASE-05Allow
Application Administrator updates one approved configuration setting.
Subject
Application Administrator
Resource
Administrative Configuration API
Action
Update bounded setting
Context
Privileged session, change approval, monitoring Healthy.
Reason
Role, session, action scope, and owner approval align.
Monitoring
Record privileged action, change reference, validation, rollback state.
API-CASE-06Deny
Supplier S requests full case details though its contract requires only service status.
Subject
Supplier Integration S
Resource
Case data outside supplier contract
Action
Read full case
Context
Well-formed request but purpose/scope exceeds contract.
Reason
Supplier trust is purpose-limited.
Monitoring
Record scope mismatch and supplier-owner review trigger.
API-CASE-07Allow temporarily
Recovery Service R requests validation state during an active recovery event.
Subject
Recovery Service R
Resource
Recovery Validation API
Action
Read validation state
Context
Active event, time-bound approval, healthy monitoring.
Reason
Recovery purpose and event scope align.
Monitoring
Record time-bound access and expiration.
API-CASE-08Reject / transition
A caller uses fictional API V1 after its approved retirement date.
Subject
Legacy Reporting Client
Resource
Deprecated API V1
Action
Generate report
Context
No approved migration extension exists.
Reason
Version lifecycle is an explicit contract decision.
Monitoring
Record V1 use and migration owner.
Scenario Decision Lab
Scenario Decision Lab 1: The Valid Request for the Wrong Team
Reporting Service Q sends a fictional request with a valid report category and date range, but requests Team Gold data while approved only for Team Blue.
API Review Questions
Ten Questions for Every API Contract
Output Question 1
Which fictional caller identity made the API request?
Output Question 2
What approved business purpose does this caller serve?
Output Question 3
Which exact resource and action were requested?
Output Question 4
What object ownership or team scope applies?
Output Question 5
Did the request meet the expected schema and business rules?
Output Question 6
Was the action independently authorized after validation?
Output Question 7
Did the response include only fields required by the caller purpose?
Output Question 8
Which API version and migration state applied?
Output Question 9
Were identity, data, supplier, monitoring, and recovery dependencies Healthy enough for the decision?
Output Question 10
Could useful monitoring metadata answer the defender question without storing full sensitive request or response content?
Safe API Errors and Logging
Eight Requirements for Safe API Errors and Minimized Diagnostics
Validation failure
Requirement
Return a safe category and enough field-level guidance for an approved caller to correct the request.
Failure pattern
Expose parser internals, private payload detail, or implementation paths.
Authorization failure
Requirement
Return a bounded denial without revealing hidden object details or internal policy structure.
Failure pattern
Return the protected data or explain hidden access internals.
Object-scope mismatch
Requirement
Preserve the denial and route legitimate ownership questions to the approved workflow.
Failure pattern
Treat a valid identifier as automatic proof of access.
Dependency unavailable
Requirement
Use a safe degraded/unavailable response and owner-visible health context.
Failure pattern
Invent data or bypass the dependency's control role.
Deprecated version
Requirement
Return safe migration/support guidance without exposing implementation detail.
Failure pattern
Keep retired behavior indefinitely with no owner.
Privileged API error
Requirement
Provide a safe reference and keep sensitive configuration diagnostics restricted.
Failure pattern
Expose configuration, secrets, or internal admin detail in the response.
Supplier API error
Requirement
Limit shared detail to contract purpose and provide a safe correlation reference.
Failure pattern
Send internal requests, secrets, or unrelated case data to the supplier.
Logging policy
Requirement
Record useful caller, resource class, action, decision, version, health, and result metadata while minimizing sensitive request/response content.
Failure pattern
Copy full sensitive payloads into general security logs by default.
Analyze the Evidence
Analyze the Service Identity Record
Service Identity P has a documented application purpose.
Its API resources and actions are bounded.
The next recertification owner is missing.
No supplied evidence shows unauthorized use.
What is the strongest response to API-E02?
API Change Review
Eight Triggers for Rechecking an API Contract
New API caller
Review question
Does the caller have a defined identity, owner, purpose, resources, actions, version, privacy, and monitoring plan?
Review action
Run caller/service-identity review before release.
New resource or action
Review question
Does the change expand authorization or object-ownership scope?
Review action
Re-run least-privilege and policy review.
Response field added
Review question
Does every caller need the new field and is its privacy classification understood?
Review action
Review minimization, authorization, retention, and logging.
Schema change
Review question
Do request validation, business rules, compatibility, and safe errors still match?
Review action
Update contract and safe regression cases.
New supplier dependency
Review question
Which data and capability cross the new ownership boundary?
Review action
Review purpose, minimization, service identity, monitoring, outage plan, and re-review.
New API version
Review question
Which authorization, data, error, dependency, privacy, and monitoring assumptions changed?
Review action
Create migration, validation, and retirement plan.
Monitoring/source change
Review question
Can current evidence still support allow/deny, health, error, and absence claims?
Review action
Update source-health rules, gaps, correlation, and owner decisions.
Recovery or major architecture change
Review question
Did time-bound access, dependencies, service identities, or resource scopes change?
Review action
Re-run API purpose, authorization, version, monitoring, and recertification review.
Scenario Decision Lab
Scenario Decision Lab 2: Deprecated Version Still in Use
A fictional API V1 reached its approved retirement date, but one internal reporting client still uses it. V2 is active and validated, and no migration extension has been approved.
Fictional Evidence
Northbridge API Defense Evidence Set
API-E01Current
Fictional API catalog
Observation
Seven Northbridge APIs have documented purpose, callers, resources, actions, response scope, and dependencies.
Supports
A structured API defense review.
Limits
Documentation does not prove every implementation follows the contract.
Review use
Build caller/resource/action and response-minimization decisions.
API-E02Conditional
Fictional service-identity register
Observation
Service Identity P has clear resource/action scope but its next recertification owner is not recorded.
Supports
Current least-privilege purpose is documented.
Limits
Lifecycle governance is incomplete.
Review use
Record an ownership Unknown and assign the service owner.
API-E03Current
Fictional reporting contract
Observation
Reporting API validates report fields separately from Team scope authorization.
Supports
Validation and authorization are distinct controls.
Limits
Does not prove every team-scope rule is correct.
Review use
Evaluate API-CASE-03 and API-CASE-04.
API-E04Current
Fictional response review
Observation
Case Status API returns status and safe summary fields rather than full case content.
Supports
Response minimization.
Limits
Does not prove every caller receives the correct object.
Review use
Review response schema plus object ownership.
API-E05Current
Fictional supplier contract
Observation
Supplier S needs only service identifier and status.
Supports
Purpose limitation and data minimization.
Limits
Does not prove all supplier retention/failure behavior is correct.
Review use
Review supplier scope, errors, monitoring, and outage behavior.
API-E06Current
Fictional version register
Observation
API V1 is scheduled for retirement after approved callers move to V2.
Supports
Defined version lifecycle.
Limits
Does not prove every caller has migrated.
Review use
Monitor version use and transition ownership.
API-E07Healthy
Fictional monitoring summary
Observation
Allow/deny decisions, privileged actions, errors, version use, dependency health, and supplier interactions are monitored.
Supports
High-level API observability.
Limits
Does not prove every alert is high quality or privacy-minimized.
Review use
Build defender questions and source-health rules.
API-E08Current
Fictional architecture change
Observation
A new mobile client is proposed as an additional caller for Profile Preferences API.
Supports
A new caller identity and contract relationship.
Limits
Does not prove the new client is unsafe.
Review use
Re-review identity, authorization, schema, response, monitoring, privacy, version, and support expectations.
Common Mistakes
Eight API Security Mistakes to Avoid
Internal API means trusted API
Why it fails
Internal connectivity does not replace caller identity, authorization, validation, object ownership, monitoring, or least privilege.
Professional correction
Treat every API relationship as governed trust.
One service identity for everything
Why it fails
Broad service identities make purpose, privilege, monitoring, and recertification harder to control.
Professional correction
Scope service identities to bounded application purposes and resource/action needs.
Valid request means authorized request
Why it fails
A structurally correct request can still target an unauthorized object or scope.
Professional correction
Keep schema validation and authorization independent.
Return every field
Why it fails
Extra response data increases privacy and exposure without helping the caller.
Professional correction
Use minimized response schemas tied to caller purpose.
Detailed errors help everyone
Why it fails
Legitimate callers need actionable failure categories, not unnecessary internal or sensitive detail.
Professional correction
Separate safe caller errors from restricted owner diagnostics.
Versioning is only naming
Why it fails
A version change can alter authorization, data, errors, dependencies, privacy, monitoring, and support.
Professional correction
Treat versions as governed contract changes.
Resource protection means blocking users
Why it fails
The defensive goal is predictable service availability for legitimate business workloads.
Professional correction
Define expected sizes, workload ranges, expensive operations, concurrency, and degraded behavior conceptually.
Prove API risk through enumeration or bypass
Why it fails
A10.5 teaches defensive design and safe review without unauthorized API testing.
Professional correction
Use fictional expected decisions, schemas, owners, monitoring, dependencies, and contract evidence.
Safe Fictional Lab
Build the Northbridge API Defense Review
Use only the fictional fields, output contexts, safe review cases, evidence records, and error examples on this page. The lab teaches contract design, privacy, authorization, output context, error handling, logging, and safe validation—not exploitation.
Phase 1 — Build the API catalog
- • Use Case Status, Case Update, Reporting, Profile Preferences, Administrative Configuration, Recovery Validation, and Supplier Status APIs.
- • Document purpose, owner, callers, resources, actions, sensitivity, dependencies, and business criticality.
- • Keep all names and identifiers fictional.
Phase 2 — Build caller identities
- • Create application, reporting, user, administrative, recovery, and supplier caller classes.
- • Assign exact service identity purpose and owner.
- • Record which APIs/actions each caller may and may not use.
Phase 3 — Build authorization rules
- • Map caller + resource + action + object ownership + business scope.
- • Create expected allow/deny cases using fictional data only.
- • Use deny by default and least privilege.
Phase 4 — Define request and response contracts
- • Create safe schemas for status, reporting, preferences, admin configuration, recovery, and supplier workflows.
- • Define required/optional fields, types, bounds, relationships, and business validation.
- • Minimize every response to approved caller purpose.
Phase 5 — Design errors and resource protection
- • Create safe fictional error categories for validation, authorization, dependency, version, and temporary service conditions.
- • Define expected request size, response size, workload, expensive-operation, concurrency, and degraded-mode concepts.
- • Do not describe bypass or evasion.
Phase 6 — Review dependencies and versions
- • Map Identity, Data, Monitoring, Supplier, and Recovery dependencies.
- • Define V1-to-V2 fictional migration ownership and retirement.
- • Identify which contract changes require privacy and authorization re-review.
Phase 7 — Build monitoring
- • Use the ten API review questions in this lesson.
- • Add source health, baselines, alert lineage, privacy/minimization, owner, and decision value.
- • State which conclusions become Unknown when monitoring is Degraded.
Phase 8 — Produce the review package
- • Create caller register, API catalog, authorization matrix, schemas, service-identity register, error policy, resource-protection plan, version register, dependency map, monitoring plan, findings, remediation owners, leadership summary, and public-safe artifact.
- • Record Unknowns rather than inventing implementation detail.
- • Do not test real APIs or send unauthorized requests.
Lab boundary
Do not use injection strings, exploit payloads, bypass examples, fuzzing, malicious markup, malicious file content, real forms, real APIs, real accounts, or real websites. Do not open or inspect suspicious files. Use harmless invented values and fictional pre-supplied metadata only.
Advanced Challenge
Redesign a Broad Internal API into Three Purpose-Limited Contracts
A fictional Northbridge internal API currently returns case data, reporting data, administrative configuration, and supplier status through one broad service identity. Redesign it without offensive testing.
Split the broad API into at least three purpose-specific contracts.
Create separate service identities with explicit owners.
Define exact resources and actions for each contract.
Add object-ownership and team-scope rules.
Create request schemas using safe fictional values.
Minimize response fields for every caller.
Define safe error categories and restricted diagnostics.
Create resource-protection expectations for size, workload, expensive operations, and degraded modes.
Create a version migration and retirement plan.
Write a leadership summary explaining how the redesign reduces unnecessary trust, data exposure, and dependency risk.
Defender Habits
A10.5 API Security Concepts Checklist
Check Your Understanding
A10.5 Mini Quiz: API Security Concepts
Choose your answers first. Explanations appear only after submission.
1. What does a fictional API service identity establish?
2. A request schema is valid but the caller lacks the requested team scope. What is strongest?
3. What is response minimization?
4. Why should service identities be recertified?
5. Why should API versions be governed?
6. What does resource protection mean in A10.5?
7. What is strongest when an API ownership rule is incomplete?
Portfolio Prompt
Portfolio Prompt: API Defense Review
Create a fully fictional A10.5 API Defense Review for Northbridge. Include API catalog; business purpose; owners; caller classes; service identities; resources; actions; object ownership; least privilege; authorization matrix; request schemas; required/optional fields; allowed values; size/range; business validation; response schemas; data minimization; safe error categories; restricted diagnostics; resource-protection concepts; workload expectations; dependencies; supplier trust; version register; migration; retirement; monitoring questions; source-health expectations; privacy/minimization; expected allow/deny cases; findings; remediation owners; validation criteria; technical summary; leadership summary; governance summary; and a public-safe API architecture diagram. Every API, caller, service identity, resource, object, version, event, and decision must be invented.
Start with caller purpose and exact resource/action need.
Keep authentication, authorization, object ownership, and validation separate.
Minimize response fields to the approved caller purpose.
Treat versions and dependencies as governed contracts.
Design resource protection around legitimate service availability, not bypass behavior.
Use fictional expected decisions instead of real API testing.
Confidence / Readiness Reflection
Are You Ready for A10.6 Secure Headers and Browser Protections?
Rate your readiness from 1 to 5 for caller identity, least privilege, object ownership, schemas, minimized responses, safe errors, resource protection, versions, dependencies, monitoring, and API governance.
I can define an API by caller, resource, action, and business purpose.
I can separate API authentication from authorization and object ownership.
I can scope service identities to exact resource/action needs.
I can create request schemas using safe fictional data.
I can minimize API responses.
I can design safe errors and restricted diagnostics.
I can explain resource-protection concepts without bypass guidance.
I can govern versions and dependencies.
I can design API monitoring around defender questions and source health.
I am ready for A10.6 browser-facing defensive layers.
Portfolio Build Guide
What a Strong A10.5 Artifact Should Show
Portfolio element 1
API catalog with purpose and owners
Portfolio element 2
Caller and service-identity register
Portfolio element 3
Resource/action matrix
Portfolio element 4
Object-ownership and scope rules
Portfolio element 5
Least-privilege authorization decisions
Portfolio element 6
Request schemas with safe fictional examples
Portfolio element 7
Minimized response schemas
Portfolio element 8
Safe error categories and restricted diagnostics
Portfolio element 9
Resource-protection expectations
Portfolio element 10
Dependency and supplier review
Portfolio element 11
Version migration and retirement plan
Portfolio element 12
API monitoring questions and source health
Portfolio element 13
Expected allow/deny decision cases
Portfolio element 14
Evidence-based findings and remediation owners
Portfolio element 15
Technical, leadership, and governance summaries
Portfolio element 16
A public-safe API review with invented details only
Key Takeaways
What You Should Remember
1.Secure APIs are explicit contracts among callers, resources, actions, ownership, schemas, responses, errors, dependencies, versions, monitoring, and owners.
2.Caller authentication does not replace authorization or object ownership.
3.Service identities need bounded purpose, least privilege, owners, monitoring, lifecycle, and recertification.
4.A valid request schema does not automatically make the requested business action authorized.
5.Response minimization limits data to what the approved caller actually needs.
6.Safe API errors separate caller guidance from restricted internal diagnostics.
7.Resource protection is about predictable legitimate availability and business-capacity design, not bypass behavior.
8.API versions can change authorization, data, dependencies, privacy, monitoring, compatibility, and support expectations.
9.Internal and supplier APIs are governed trust relationships rather than automatically trusted connections.
10.A10.5 prepares you for A10.6, where browser-facing protections are reviewed as another layer of the web defense architecture.
Safety Boundary
Defensive API Review — No Enumeration, Fuzzing, or Unauthorized Requests
Nothing in A10.5 authorizes testing real APIs, endpoints, accounts, service identities, resources, identifiers, versions, suppliers, credentials, tokens, or rate controls. Do not enumerate, fuzz, modify identifiers, send unauthorized requests, attempt object-level access, bypass authorization, guess credentials, capture tokens, test resource limits, or construct exploit payloads. Use only fictional contracts, expected decisions, monitoring evidence, and safe review questions.
Lesson Complete
Continue to Secure Headers and Browser Protections
A10.5 established API callers, service identities, authorization, object ownership, schemas, minimized responses, safe errors, resource-protection concepts, versions, dependencies, monitoring, and resilience. A10.6 will focus on browser-facing defensive layers such as transport expectations, content restrictions, framing, cookie protections, referrer privacy, compatibility, exceptions, rollout, monitoring, validation, and rollback.