Web and API security is mostly about boundaries, input, and trust

The boundary questions

A web application should know who is making a request, which object or action that identity may access, whether the input is valid, and what should happen when a dependency or exceptional condition fails. Broken access control exposes another user’s data or actions. Authentication failures weaken identity checks. Injection lets untrusted input alter an interpreter’s intended command or query.

APIs make object decisions visible

APIs often expose structured operations over accounts, orders, files, or devices. A valid login is not enough; the service must enforce authorization for each object and function, manage resource use, protect sensitive flows, and keep an accurate inventory of endpoints and versions.

Use frameworks as checklists, not proof

The OWASP Top 10:2025 and API Security Top 10 organize recurring risk families. They do not certify an application and should not replace threat modeling, code review, testing, secure defaults, dependency controls, useful logging, and verification after remediation.

Test the object and action together

An application can correctly authenticate a user and still expose another user’s record when the server trusts an object identifier or client-side role. For each sensitive action, ask which identity may perform it, on which object and under which business condition. The server must enforce that answer even when a request is sent outside the normal interface.

Error handling should not become disclosure

Validation, rate limits and clear failure states can reduce abuse, but responses should not reveal secrets, internal paths or more account detail than the user is allowed to know. Logging needs enough context for investigation without placing passwords, tokens or sensitive payloads in routine records. Security belongs in the data and authorization design, not only at the network edge.

Example: the mobile app is not the security boundary

A mobile interface may hide an administrative action, but an attacker can call the API directly. The server must authenticate the caller, authorize the action on the requested object and validate the submitted data. Client-side visibility can improve usability; it cannot substitute for server-side enforcement. Rate limits and monitoring add context but do not repair a missing permission check.

Review one transaction end to end

Choose a sensitive action such as changing a payout destination. Trace identity, session, object ownership, input validation, business approval, logging and notification. Ask how retries and partial failures behave. One end-to-end review often reveals gaps between teams that a generic checklist misses, while keeping the analysis tied to an authorized, concrete use case.