Web security: understand the essential protections of a website

Web security is not a single switch. It is a set of layers that reduce different risks: encrypted transport, browser restrictions, dependency integrity, authentication and authorization. This collection focuses on technical website security. Privacy and Local First answer a different question: where data goes and what it reveals.

Think in layers, not in miracle settings

HTTPS protects traffic in transit but does not fix vulnerable application code. A Content Security Policy can reduce the impact of some injections, but it does not replace output escaping or input validation. A strong password does not compensate for broken authorization.

A coherent baseline combines HTTPS, security headers, CSP, SRI where appropriate, sound authentication and sessions, and hashes for integrity checks.

Start with a simple threat model

Ask what you are protecting, from whom and on which surface. A static site, an account-based application and an administration panel do not expose the same risks. Identify sensitive data, privileged actions, third-party resources, embeddable pages and browser-accessible APIs.

HTTPS is the foundation, not the whole building

HTTPS encrypts traffic between browser and server and lets the browser authenticate the server certificate. It does not stop XSS, compromised credentials, broken access control or dangerous JavaScript dependencies. HSTS can then tell browsers to keep using HTTPS; the HTTP security headers guide explains the surrounding policy.

Reduce the attack surface

Remove unused dependencies, restrict iframe and browser permissions, never ship secrets in client code and keep components updated. Every third-party script expands what your page trusts. CSP controls permitted sources, while SRI can pin the expected bytes of selected static resources.

Authentication, authorization and sessions differ

Authentication asks who a user is; authorization asks what that user may do; a session carries identity between requests. JWT can be part of that design but does not replace authorization checks. See the JWT guide and password guide.

Test behavior, not configuration files

Inspect the headers actually returned, CSP violations, third-party loads, unauthenticated routes and expired-session behavior. A protection written in a configuration file but absent from the final response protects nothing.

For privacy-oriented processing, see Local First, PDF privacy and image metadata and privacy.

For the relationships between authorization flows, tokens and public keys, continue with OAuth 2.0, PKCE, JWT, JWK and JWKS. To choose between confidentiality, integrity and authentication mechanisms, see encryption, hashing and HMAC.