How Security Works

OAuth 2.0 is an authorization framework that lets users grant third-party applications limited access to their accounts without sharing their password. When you click "Login with Google", OAuth is what happens: Google verifies your identity and issues your app a short-lived access token proving you're allowed to read the user's profile. OpenID Connect (OIDC) is a thin identity layer on top of OAuth 2.0 that also tells the app who the user is. Together they power every "Login with X" button on the internet.

A JSON Web Token (JWT) is a compact, URL-safe token that encodes claims (user ID, roles, expiry) as a signed JSON payload. The server signs the token with a secret key; any server with the same key can verify the signature and trust the claims — without a database lookup. This makes JWTs stateless: your API can validate a token in microseconds just by verifying the signature. They are the most common token format for APIs, OAuth 2.0 access tokens, and authentication systems.

Encryption transforms readable data (plaintext) into unreadable ciphertext using a mathematical key. Only someone with the correct key can decrypt it back. Modern systems use two complementary types: symmetric encryption (one key encrypts and decrypts — fast, ideal for bulk data) and asymmetric encryption (a public key encrypts, a private key decrypts — slower, but solves the key distribution problem). TLS, HTTPS, end-to-end messaging, and disk encryption all combine these two types together.

API authentication is how a server verifies who is calling it before serving a request. Because APIs are consumed by other software rather than people at a login form, they use credentials that travel with each request: an API key, a bearer token (often a JWT), an OAuth access token, an HMAC signature, or a client certificate (mTLS). Each method trades simplicity against security and revocability. Choosing the right one depends on who the caller is and what the API protects.

PKCE (Proof Key for Code Exchange) hardens the OAuth 2.0 authorization code flow against interception attacks. The flow exchanges a temporary authorization code for tokens, but on public clients — single-page apps and mobile apps that cannot keep a secret — an attacker who steals the code could redeem it. PKCE fixes this: the client generates a random secret (the code verifier), sends only a hash of it (the challenge) up front, and proves it holds the original when redeeming the code. It is now recommended for all clients.

The TLS handshake is the negotiation that happens before any HTTPS data is exchanged. It lets a client and server agree on encryption, verify the server identity via a certificate, and securely establish a shared session key — all over an insecure network. It cleverly uses slow asymmetric cryptography just to set up a fast symmetric key that encrypts the actual traffic. TLS 1.3 streamlined this to a single round trip and mandated forward secrecy, making HTTPS both faster and safer.

Password hashing is how systems store passwords without keeping the actual password. Instead of the plaintext, you store a one-way hash — a transformation you cannot reverse. At login you hash the entered password and compare. But fast hashes are crackable, so passwords use slow, adaptive algorithms (bcrypt, scrypt, argon2) and a unique random salt per password to defeat precomputed rainbow tables. Done right, even a stolen database does not hand attackers usable passwords.

SQL injection is a vulnerability where an attacker inserts malicious SQL through user input that an application concatenates directly into a query. Because the input becomes part of the query text, the attacker can change what the query does — reading other users data, bypassing login, or destroying tables. It remains one of the most damaging web vulnerabilities. The definitive fix is parameterized queries (prepared statements), which keep data separate from code so input can never alter query structure.

Cross-site scripting (XSS) is a vulnerability where an attacker injects malicious JavaScript into a web page that other users view. When the victim browser renders the page, it runs the attacker script as if it came from the trusted site — letting it steal session cookies, capture keystrokes, or perform actions as the user. XSS comes in stored, reflected, and DOM-based forms. The core defence is treating all user data as untrusted: encode it on output and lock down what scripts can run with a Content Security Policy.

Cross-site request forgery (CSRF) tricks a logged-in user browser into sending an unwanted authenticated request to a site they trust. Because browsers automatically attach cookies to requests for a domain, a malicious page can make the victim browser perform actions — transfer money, change an email — on a site where the victim has an active session, without the victim intending it. The defences are CSRF tokens (a secret the attacker cannot know) and SameSite cookies (which stop cookies riding on cross-site requests).

CORS (Cross-Origin Resource Sharing) is a browser mechanism that controls whether a web page on one origin may make requests to a different origin. By default, the same-origin policy blocks such cross-origin requests to protect users. CORS lets a server opt in by sending specific Access-Control headers that tell the browser which origins, methods, and headers are allowed. It is enforced by the browser, not the server — which is why a CORS error means the browser blocked the response, not that the request failed.

Zero trust is a security model built on the principle "never trust, always verify." Traditional security trusted anything inside the corporate network perimeter — but once an attacker got inside, they could move freely. Zero trust removes that implicit trust: every request, whether from inside or outside, must be authenticated and authorized based on identity, device health, and context, and granted only the minimum access needed. The network location no longer confers trust; verified identity does.

The OWASP Top 10 is a widely referenced list of the most critical web application security risks, published by the Open Worldwide Application Security Project. It is not a checklist of specific bugs but a set of risk categories — like broken access control, injection, and cryptographic failures — that consistently cause real breaches. Developers use it as a baseline: understand each category, know how it happens, and apply the standard defences. It is essential knowledge for building secure applications and a common interview topic.