Web, Browser and HTTP Deep Dive — DedSec Project

Purpose: Understand the protocol and browser security model underneath modern web applications so application-security findings can be reasoned about rather than memorized.

Learning objectives

• Explain HTTP requests/responses, methods, status codes, headers, caching, cookies, and content types.
• Understand origins, same-origin policy, CORS, CSP, browser storage, and session boundaries.
• Distinguish authentication, session management, authorization, and CSRF protections.
• Understand why HTTP/2 and HTTP/3 change transport behavior without eliminating application-layer risks.
• Build safe localhost experiments that show the protocol clearly.

Anatomy of an HTTP request

A request contains a method, target, headers, and sometimes a body. Important methods include GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS. Method names describe intent but do not enforce authorization. Server-side policy must decide whether the caller may perform the action.

Important request headers include Host, Content-Type, Accept, Authorization, Cookie, and conditional/caching headers. Treat headers received through proxies carefully: a server should have an explicit trust model for forwarded client-address, scheme, and host information.

Anatomy of an HTTP response

A response includes a status code, headers, and usually a body. Security-relevant headers can influence caching, browser execution policy, transport behavior, framing, MIME handling, and cookie policy. Application code still needs secure authorization and data handling even when headers are configured well.

Origins and the browser security model

An origin is based on scheme, host, and port. The same-origin policy limits how documents/scripts from one origin can interact with resources from another. CORS selectively relaxes parts of this policy for HTTP requests. CORS is not a server-side authorization mechanism: a non-browser client is not constrained by browser CORS enforcement.

Cookies and sessions

Session cookies should be treated as credentials. Important attributes include:

• Secure to restrict transmission to secure transport;
• HttpOnly to reduce script access;
• SameSite to control cross-site sending behavior;
• appropriate Path/Domain scope;
• expiration aligned with the session policy.

Session design should include rotation at important authentication transitions, logout/invalidation behavior, idle/absolute timeouts where appropriate, and server-side authorization on every protected operation.

Browser storage

Cookies, local storage, session storage, IndexedDB, caches, and service workers have different lifecycles and exposure. Avoid placing long-lived high-value secrets in browser-accessible storage unless the architecture explicitly requires and protects them. Threat modeling should include browser extensions, XSS, shared devices, and session recovery.

CSRF

Cross-site request forgery abuses a browser's ability to send ambient credentials such as cookies. Defenses may include SameSite cookie policy, anti-CSRF tokens, origin/referer validation where appropriate, and avoiding unsafe state changes through requests intended to be idempotent. The correct defense depends on the application architecture.

Content Security Policy

CSP can reduce the impact of some content-injection problems by controlling allowed script/style/resource sources and execution behavior. It is a defense-in-depth control, not permission to ignore output encoding, template safety, DOM APIs, or dependency trust.

Caching and sensitive data

Understand where responses can be cached: browser, shared proxy, CDN, service worker, or application cache. Sensitive responses need appropriate cache policy. Authentication state should not be inferred from stale client-side cache alone.

HTTP/2 and HTTP/3

HTTP/2 multiplexes streams over a connection; HTTP/3 runs over QUIC. These protocols improve transport behavior but the application still uses concepts such as methods, headers, authority, authentication, and authorization. Infrastructure components must agree on request interpretation; inconsistent parsing between layers can create security problems.

Error handling

Modern secure design includes exceptional conditions. Errors should:

• fail safely;
• avoid revealing secrets or unnecessary internals;
• produce useful correlation identifiers for operations;
• return consistent client behavior;
• log enough context for diagnosis without logging sensitive values;
• avoid turning unexpected input into an authorization bypass.

Local protocol exercise

Start a loopback-only server as shown in Module 51. Use curl -i to view response headers from your own service:

curl -i http://127.0.0.1:8000/

Create a simple local application later and compare GET versus POST, different content types, and intentional 4xx/5xx errors. Your goal is to observe protocol behavior, not bypass controls.

Application authorization exercise

Build a tiny local app with two synthetic users and two objects. Write automated tests asserting that:

• each user can access their own object;
• each user is denied access to the other's object;
• anonymous users are denied;
• invalid object IDs fail safely;
• denied actions generate an appropriate audit event.

This teaches object-level authorization more effectively than memorizing vulnerability names.

Review checklist

When reviewing a web feature ask:

1. Who can call it?
2. What identity does the server trust?
3. What object/action is being authorized?
4. What input formats and size limits apply?
5. What happens on malformed or duplicate input?
6. Where does output enter HTML/JS/SQL/OS/template contexts?
7. Which cookies/tokens are used and how do they expire?
8. Which origins are trusted and why?
9. What security headers are appropriate?
10. Which logs prove success, failure, and privileged changes?

Checkpoint

You are ready to continue when you can explain an HTTP transaction end to end and distinguish browser-enforced policy from server-side authorization. Continue with Modules 11, 14, 22, 39, and 40.

Guided study workflow

Before you begin

Modules 11 and 51 help.

Practice task

Use a local app/service you own to observe requests, responses, headers, cookies, errors, and authorization tests. Keep the exercise local and synthetic.

Continue with

Recommended next modules: 14, 22, 39, 40.