Web applications

A web application receives messages and makes decisions. A book reservation might require a valid session, permission to use the account, an available copy, and a consistent database update. Security includes all these rules and extends beyond the sign-in screen.

HTTP defines application messages and semantics. It uses an underlying transport; HTTP/3 uses QUIC, while earlier common deployments use TCP. HTTPS protects communication in transit but does not decide who may edit an object or whether an application implements its business rules correctly.

Read the request’s purpose

A request has a method, destination, headers, and sometimes a body. Those fields can carry identifiers, user text, session evidence, and choices. A field’s name does not establish that its value is trustworthy.

For a fictional reservation, identify the book, account context, and desired action. The server should derive trusted identity from validated session evidence, verify the relevant permissions, and apply its reservation rules. It should not assume that a submitted account label is proof.

A request map records purpose, inputs, state changes, data sensitivity, and access rules. It includes reads as well as writes: an unauthorized disclosure can occur without changing the underlying record. A successful response code alone proves neither correct authorization nor successful business processing.

Authentication and authorization

Authentication establishes confidence in an account context. A cookie can maintain a session; a JWT is a token format; an API key may identify an application; a certificate-based method proves possession under a trust configuration. None is a universal substitute for validation.

Authorization decides whether that actor may act on this resource now. It can apply to authenticated or anonymous users. Ownership, role, organization, workflow stage, and other policy inputs may matter. Hiding a button helps the interface but cannot enforce an API’s permissions.

A member can reserve books. Can they edit every reservation?

No. Permission to use a feature and permission over a particular object are separate decisions. The service must check the reservation's owner and any legitimate staff role for each protected action.

Data must remain data

Injection occurs when untrusted content affects instructions or syntax. The relevant interpreter determines the prevention: parameterized database operations, context-appropriate output encoding, safe APIs, and tightly constrained dynamic choices have different jobs.

There is no single escaping function that safely handles SQL, HTML, shell syntax, and every template language. Parameterization also does not automatically cover identifiers or other elements a database API cannot bind; those choices need suitable design and validation.

File access and server-side fetching have additional boundaries. A syntactically valid path or URL may identify a resource the application should not access. Restrict permitted resources and operations independently of parsing.

Browser protections have specific roles

The Same-origin policy limits cross-origin script access, especially reading responses. Some cross-origin requests and embedded resources are permitted. CORS allows servers to declare selected cross-origin browser access; it does not replace authentication or authorization, and a failed browser read does not prove a request had no effect.

Cookies have distinct protections. Secure restricts transport, HttpOnly restricts script access to the cookie, and SameSite influences cross-site sending. Their exact behavior depends on browser rules and configuration.

CSRF abuses credentials the browser attaches automatically to an unwanted request. Appropriate request tokens, origin checks, and cookie policy help establish request legitimacy. XSS involves unauthorized script execution in a browser context. It may perform actions or read available page data even when HttpOnly prevents directly reading a session cookie. Cookie theft is not its only possible impact.

Choose a deeper lesson

A useful finding connects the observed behavior to an intended rule, affected data or action, and a specific correction. Distinguish what was observed from assumptions, and preserve only the sanitized evidence needed to explain the problem.

Work a request through five decisions

Consider an invented library service. Member Lina asks to cancel reservation R42. The session record identifies Lina, R42 belongs to Jo, and the policy permits cancellation only by the reservation owner or a librarian. Lina has the member role. These supplied facts are enough to decide the permission question: deny this cancellation.

Authentication succeeded, but it supplied only one input to authorization. The identifier R42 selects the object; it does not establish a relationship to Lina. A server should evaluate the actor, action, resource, and current policy before applying a state change. It should also return only the information that the caller is permitted to receive.

PredictThe interface hides the cancel button for R42. Does that change the server’s decision?

The decision remains deny. Hiding an unavailable action helps users, but a client interface is not the authority for the service. The same policy must cover browser, mobile, and other supported clients.

Now add a permitted cancellation of Lina’s own reservation. Permission alone does not settle concurrency: the reservation might already have been fulfilled. The service needs a defined state transition and a consistent update. If it later renders Lina’s explanation, that text needs a suitable output context. If it caches the response, its sharing policy must match the audience.

A useful review follows the same request through five questions: who is acting, which object is involved, which action is allowed now, how data is interpreted, and where the result may be retained or shared. The supplied records establish the R42 decision; they do not demonstrate that the deployed code implements it. That requires implementation and verification evidence.