API security and session hijacking: protecting authenticated access
Understand API security, session hijacking, and practical checks for authentication, authorization, and session lifecycle.
## What is API security?
**API security** is the practice of protecting application programming interfaces and the data and operations exposed through them. An API may be used by a browser, mobile application, partner or another service. Security depends on identifying callers where appropriate, checking what each caller may do, limiting misuse, and monitoring the interface throughout its lifecycle. Authentication identifies a caller; authorization determines which resources and actions that caller may access. [OWASP API Security Top 10, 2023](https://api-security.owasp.org/editions/2023/en/0x11-t10/) describes common API risks.
One common failure is **broken object-level authorization**: an endpoint accepts an object identifier but does not adequately verify whether the caller may access that particular object. For example, a document API must check access to the requested document on the server, not merely rely on a hard-to-guess ID or the client hiding a button. OWASP recommends authorization checks in functions that access data using a user-supplied ID. [OWASP API1:2023](https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/).
## What is session hijacking?
**Session hijacking** occurs when an unauthorized party takes over or uses an active session, often by obtaining a valid session identifier or token. A session token can represent an already authenticated user, so possession may allow reuse without knowing the password; depending on the system, an already established session may also be reused despite a prior multi-factor authentication step. A session is not the same thing as a password, and stealing a token is only one route to session hijacking. [MITRE ATT&CK: Steal Web Session Cookie](https://attack.mitre.org/techniques/T1539/).
An attacker might steal a browser cookie through malicious software, injected script, or a phishing proxy. In another scenario, session fixation causes a victim to authenticate using an attacker-known session identifier. These scenarios have different prerequisites and defenses. API credentials and bearer tokens can also be stolen and replayed, though not every API token represents a browser session.
## Reduce risk across the session lifecycle
Use HTTPS for the full session and protect tokens from disclosure. For browser session cookies, apply appropriate Secure and HttpOnly attributes and select a SameSite policy suitable for the application; these settings reduce particular risks but do not make a compromised endpoint or browser safe. Generate unpredictable session identifiers and rotate them after authentication or privilege changes to reduce fixation risk. Use server-enforced idle and absolute expiration, and revoke sessions on logout or suspected compromise. Design revocation with the application’s token format and deployment architecture in mind. [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html).
At each sensitive API operation, enforce object- and function-level authorization on the server. Validate inputs, apply resource limits, maintain an inventory of endpoints and versions, and test access across users and roles. Monitor for suspicious session reuse or unusual activity, but treat location and device changes as signals requiring investigation rather than proof of compromise. Reauthentication or step-up checks can protect sensitive actions; no individual control guarantees prevention.