Web Application and API Security Operations

Authentication is not authorization

Web applications and APIs process HTTP methods, sessions, tokens, input, file uploads, webhooks, third-party calls, and administrative operations. Authentication establishes a claimed identity or session. Authorization decides whether that identity may perform a specific action on a particular function, tenant, object, or data set. Both require clear lifecycle, error, logging, and ownership decisions. A gateway, security header, WAF, or rate limit can help reduce risk, but none alone guarantees application security or prevents abuse.

API inventory template

Record	Questions to answer
Endpoint and version	Purpose, owner, lifecycle, clients, deprecated status, and change control.
Identity and authorization	Accepted session or token, issuer and audience checks, object and function rules, and admin separation.
Input and output	Schema, size and request limits, file handling, encoding, error behavior, and sensitive fields.
Operations	Logging, rate-limit behavior, alerts, dependencies, support access, and rollback or deprecation plan.

Web and API security review checklist

Inventory current, versioned, deprecated, internal, partner, and administrative endpoints. Unknown endpoints cannot receive a reliable lifecycle review.
Define authentication and authorization separately for every privileged operation, tenant boundary, and object access path.
Validate requests at the appropriate boundary with schema, type, size, and business-rule checks; encode outputs for their destination context.
Use bounded session and token lifecycles, secure logout or revocation behavior where supported, and safe handling of expired or malformed credentials.
Review CORS, CSRF, security headers, file-upload paths, webhooks, and third-party dependencies according to the application design.

Operational validation workflow

Select a high-value workflow such as account administration, document access, payment change, or integration setup.
Confirm expected client, identity, authorization decision, request schema, rate behavior, logs, and support ownership.
Use approved test accounts and representative data to verify permitted and denied behavior. Do not use production secrets or unapproved testing against third parties.
Review safe error responses and monitoring: errors should aid operators without exposing unnecessary implementation or sensitive data to clients.
Record the endpoint version, evidence, limitations, next review, and deprecation work where applicable.

Fictional API workflow

A customer portal offers an API to retrieve invoices. A design review finds the endpoint validates a valid session but relies on an invoice identifier without confirming the invoice belongs to the caller's organization. The team adds a server-side ownership check, logs denied authorization decisions with bounded identifiers, updates the API contract, and validates client compatibility. The change addresses a specific authorization boundary; it does not make every API path automatically safe.

Common mistakes

Common mistakes include equating a valid token with allowed access, leaving deprecated endpoints undocumented, returning detailed internal errors, or making rate limits the only abuse control. Monitoring should preserve useful evidence, but logs also need retention, access control, and review ownership. A clean response from a tool or test does not prove all clients, versions, and data states behave correctly.

Authentication and authorization questions

For each important operation, ask which identity is accepted, how it is bound to a session or token, which tenant and object are in scope, whether the operation is permitted for that role, and how a denial is handled. Review service-to-service calls and administrative APIs independently from browser traffic. Record token issuer, audience, expiration, and revocation expectations where relevant. A successful user journey can coexist with an authorization gap in a less common operation, version, integration, or error path.