Web Application Security Basics: Risks Every Builder Should Check

Broken access control

The most common serious flaw is letting users act on data or functions they should not reach: reading another learner's progress by changing an ID in the URL, or calling an admin endpoint as a normal user. Enforce authorisation on the server for every request, against the specific resource being accessed. Deny by default, centralise permission checks and write tests that try to access other users' data.

Injection

Injection happens when untrusted input is interpreted as part of a command or query: SQL injection, command injection or template injection. Use parameterised queries or a query builder for all database access, avoid passing user input to shell commands and use templating engines with automatic escaping. Cross-site scripting, a closely related risk, is prevented by escaping output in context and sanitising any HTML you must render.

Authentication and session weaknesses

• Hash passwords with a slow, salted algorithm such as Argon2id, scrypt or bcrypt.
• Rate-limit login, password reset and verification endpoints.
• Offer or require multi-factor authentication for sensitive accounts.
• Use secure, HttpOnly, SameSite cookies for sessions and protect state-changing requests against CSRF.
• Expire sessions appropriately and invalidate them on logout and password change.

Cryptographic failures and data exposure

Serve everything over HTTPS, protect sensitive data at rest where appropriate and never invent your own cryptography. Minimise the personal data you collect and keep, and avoid putting sensitive data in URLs, logs or analytics events. Store secrets in a secret manager, not in code or configuration files committed to version control.

Security misconfiguration

Default credentials, verbose error pages with stack traces, open cloud storage buckets, unnecessary services and missing security headers are common and easy to exploit. Use secure defaults in every environment, disable debug features in production, apply least-privilege permissions to infrastructure and add headers such as Content-Security-Policy, Strict-Transport-Security and X-Content-Type-Options.

Vulnerable dependencies and supply chain

Modern applications include hundreds of third-party packages. Use lock files, enable automated dependency alerts, update regularly and review new dependencies before adding them. Pin and verify build tools and CI actions, restrict who can publish your packages and treat the build pipeline as part of your attack surface.

Server-side request forgery and file handling

Features that fetch URLs supplied by users, such as importing a document from a link, can be abused to reach internal services. Allow only expected schemes and destinations, block internal network ranges and fetch from an isolated environment where possible. For uploads, validate type and size, store files outside the web root with generated names and scan or process them in isolation.

Logging, monitoring and response

Without useful logs and alerts, attacks go unnoticed. Log authentication events, permission failures and administrative actions with enough context to investigate, excluding secrets. Alert on unusual patterns, and write a short incident response plan that names who to contact and how to rotate credentials.

Checklist

• Every request is authorised against the specific resource
• Queries are parameterised and output is escaped
• Passwords, sessions and logins follow current practice
• Data is encrypted in transit and secrets are managed
• Production configuration is hardened with security headers
• Dependencies and the build pipeline are maintained and protected
• User-supplied URLs and files are handled safely
• Security events are logged, monitored and acted on