Web Security

Web security is the work of keeping a web application’s data and actions available only to the people and systems that should use them, while making abuse detectable and containable. It is not a browser-header exercise. A request travels through the browser, network edge, application, data stores, identity provider, dependencies, and deployment system. Each handoff is a trust boundary.

The useful question is not "is this page secure?" Ask what the requester can cause the system to do, what data can cross the boundary, and which component makes the final decision. The application server must decide whether an authenticated identity may perform a requested action on a specific object. A hidden button, a client-side route check, or an identifier that looks hard to guess does not make that decision.

The mental model

Start with four control families.

Identity and access. Authentication establishes who or what made a request. Authorization decides whether that identity may perform this action on this object. Session management binds an authenticated user to later HTTP requests. These are related but distinct controls. A valid session does not authorize every action.

Data handling. Treat request parameters, headers, cookies, uploaded files, messages, and third-party responses as untrusted until the receiving component has checked them. Keep data separate from interpreter syntax with parameterized interfaces. When rendering user-controlled data, encode it for the exact HTML, attribute, URL, CSS, or JavaScript context. If users must author HTML, sanitize an allowed subset instead of treating it as ordinary text.

Browser and transport boundaries. HTTPS protects traffic in transit. Cookie attributes constrain how browsers expose and send session cookies. Content Security Policy constrains resources that a browser may load. These controls reduce exposure, but they do not replace server-side authorization or safe output handling.

Delivery and detection. Configuration, dependencies, build systems, deployment artifacts, and logs are part of the application’s attack surface. Review them with the same care as source code. Record security-relevant events, protect the records, and avoid placing credentials or session material in them.

The OWASP Top 10 is an awareness document that groups common web application risks. The 2025 edition includes broken access control, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, integrity failures, logging and alerting failures, and mishandling exceptional conditions. Use it to orient a conversation about risk, not as a complete test plan.

For a testable baseline, use the OWASP Application Security Verification Standard, or ASVS. It supplies requirements that developers, reviewers, testers, and buyers can use to define what must be verified. The standard turns "we care about security" into controls with evidence.

How the controls fit together

Imagine a user requesting an invoice. The browser sends an identifier and a session cookie. The server authenticates the session, obtains an identity, and checks whether that identity may read that invoice in the relevant tenant. It loads the record using a parameterized query, returns only the allowed fields, and encodes any user-authored values before rendering them. Logging records the decision and relevant request context without recording the session identifier.

A flaw in any stage can undo the others. Correct authentication with missing object-level authorization exposes another customer’s invoice. Correct authorization with an injection flaw can expose data through a different path. A well-built application with an exposed administrative configuration or compromised dependency still has a problem. Security comes from connected controls, verified as a system.

Where this course stops

This is an orientation to web application security. It does not replace a threat model, an ASVS assessment, a penetration test, framework-specific guidance, or incident response practice. It also cannot tell you the right risk decision for your data, users, and architecture. Those decisions require a defined system and evidence.

A useful next path is: learn the HTTP and browser model; build authentication, authorization, sessions, and safe data flows in one framework; use the OWASP Cheat Sheet Series while implementing; then assess a real application against a selected ASVS level. Add threat modeling, dependency and build integrity, logging, and review gates as normal delivery work.