18
F 18
WEB APP
Web Application Security: Protecting Modern Websites
Web application security covers the practices, tools, and architecture decisions that keep browser-facing software safe from exploitation — spanning everything from how a server handles untrusted input to how a browser enforces same-origin boundaries. Because a web app is reachable by anyone with a URL, it sits on the internet's most exposed edge, and a single overlooked endpoint can expose an entire backend.
- HTTPS enforced everywhere, no mixed content
- Security headers: CSP, X-Content-Type-Options, HSTS
- Continuous dependency & vulnerability scanning
19
F 19
API
API Security: Protecting the Backbone of Modern Applications
Modern products are assembled from APIs — mobile apps, single-page frontends, and partner integrations all talk to the same backend endpoints, often bypassing the protections a traditional web page relies on. That makes API security its own discipline: verifying every caller's identity, enforcing limits, and validating payloads at each endpoint rather than trusting that only the "real" frontend will ever call it.
- Strong authentication on every endpoint, no exceptions
- Rate limiting and throttling per client
- Strict schema and payload validation
20
F 20
ACCESS CONTROL
Authentication vs. Authorization: Understanding the Difference
Authentication answers "who are you?" — confirming an identity via a password, token, or biometric. Authorization answers "what are you allowed to do?" — deciding whether that verified identity can touch a specific resource or action. Conflating the two is a common root cause of access-control bugs: systems that authenticate correctly but forget to re-check authorization end up exposing other users' data.
- Keep authentication and authorization as distinct layers
- Re-check permissions on every request, not just at login
- Default to least privilege for every role
21
F 21
AUTH
How Multi-Factor Authentication Improves Security
MFA requires a second proof of identity beyond a password — something the user has, is, or knows in addition to the password itself. Because stolen or guessed passwords remain the leading cause of account takeover, adding one independent factor means a single leaked credential is no longer enough on its own to compromise an account.
- Prefer app-based TOTP or hardware keys over SMS
- Require hardware keys for admin and high-value accounts
- Make MFA mandatory, not opt-in, on privileged roles
22
F 22
AUTH
Secure Password Practices for Developers and Users
For users, a unique, long passphrase kept in a password manager beats a "clever" but reused password every time. For developers, the responsibility looks different — never store passwords in plaintext or with reversible encryption, and never roll a custom hashing scheme. Modern systems hash passwords with slow, salted algorithms built specifically to resist brute-forcing at scale.
- Hash with bcrypt or Argon2, with a unique salt per user
- Check new passwords against known-breach lists at signup
- Skip complexity theater in favor of length
23
F 23
TOKENS
JWT Security: Common Mistakes Developers Should Avoid
JSON Web Tokens are a compact way to carry identity claims between parties, but their flexibility invites mistakes. Common pitfalls include trusting the algorithm named inside the token itself, storing tokens where client-side scripts can read them, and never expiring or revoking a token once it's been issued.
- Pin the expected signing algorithm on the server side
- Use short expiry windows paired with refresh tokens
- Store tokens in httpOnly, secure cookies where possible
24
F 24
SECURE CODING
Secure Coding Practices Every Developer Should Know
Most vulnerabilities aren't exotic — they're the accumulated result of ordinary coding habits that skip validation, trust input, or handle errors carelessly. Secure coding treats every external input as hostile by default, fails safely when something goes wrong, and keeps dependencies patched, turning security into a property of how code gets written day to day rather than a step bolted on afterward.
- Validate input and encode output, every time
- Run dependency and software-composition scans in CI
- Review code against a shared security checklist
25
F 25
FRAMEWORK
OWASP Top 10: Understanding the Biggest Web Application Risks
The OWASP Top 10 is a periodically updated, community-researched ranking of the most critical web application security risks, from broken access control and cryptographic failures to injection and security misconfiguration. It functions as a shared vocabulary and a prioritization tool — a starting checklist for what to test, train on, and defend against first.
- Map internal test coverage to the current Top 10
- Re-check assumptions when a new revision ships
- Use it to triage and prioritize the remediation backlog
26
F 26
API
How to Secure a REST API
Securing a REST API means treating every endpoint as a potential entry point: authenticate every call, authorize each action against the specific resource being touched, validate and constrain all input, and never return more data than the caller actually needs. Transport encryption and careful, generic error handling round out a baseline that resists both casual abuse and a targeted attempt.
- TLS on every connection, no unencrypted fallback
- Token-based auth scoped to specific permissions
- Consistent, generic error responses that don't leak detail
27
F 27
INPUT HANDLING
Input Validation and Why It Matters for Application Security
Nearly every major class of web vulnerability — injection, cross-site scripting, path traversal — begins with input that wasn't checked before it was trusted. Input validation constrains what a system will accept in the first place, rejecting anything outside an expected shape, length, or character set, and pairs with output encoding to neutralize whatever slips through anyway.
- Validate against an allow-list, not a deny-list
- Enforce validation server-side, never client-side only
- Encode output based on where it's rendered