Web Application Security Checklist 2026: OWASP Top 10 for UK Startups

Why security matters from day one

You don't need enterprise-grade security to launch. But you do need to avoid obvious vulnerabilities. Hackers are automated — they scan every website for common holes. Fix the top 10 OWASP vulnerabilities and you'll be ahead of 80% of the web.

Beyond automated attacks, you have compliance obligations. If you handle any customer data in the UK, you're subject to GDPR. Handle payment information, you're under PCI-DSS (or use Stripe, which handles it for you). Handle healthcare data, you're under security regulations. Start secure — it's easier than retrofitting it later.

The OWASP Top 10 vulnerabilities: What they are and how to fix them

1. Broken Access Control

What it is: Users can access resources they shouldn't. An admin-only page is accessible to regular users. A user can view another user's private data.

How to fix it:

• Check permissions on every API endpoint: "Is this user allowed to perform this action on this resource?"
• Never trust the frontend. Someone can edit JavaScript to bypass frontend checks.
• Use role-based access control (RBAC): Define roles (admin, member, viewer) and what each can do.
• Test every feature as a logged-in user, then as an unauthenticated user, then as a user from a different workspace/organization.

2. Cryptographic Failures

What it is: Sensitive data (passwords, credit cards, API keys) is stored in plain text or with weak encryption.

How to fix it:

• Never store passwords. Hash them with bcrypt, Argon2, or scrypt. Never use MD5 or SHA1.
• Use HTTPS everywhere. Get a free SSL certificate from Let's Encrypt.
• Never store credit cards. Use Stripe or a payment processor that's PCI-compliant.
• Encrypt sensitive data at rest (database) and in transit (over the wire).
• Don't log passwords or sensitive data. Scrub logs.

3. Injection Attacks (SQL, NoSQL, Command)

What it is: An attacker passes malicious input that changes the meaning of your database query or system command. Example: username input `admin' OR '1'='1` bypasses authentication.

How to fix it:

• Use parameterized queries or prepared statements. Never concatenate user input into SQL.
• Use an ORM (SQLAlchemy, Sequelize, etc.) — they default to safe queries.
• For NoSQL, use validation libraries to whitelist input types.
• Avoid shell commands with user input. If necessary, use allowlists.
• Sanitize input: validate type, length, format before processing.

4. Insecure Design

What it is: Your architecture lacks security controls. Password reset tokens don't expire. You store all user data in one unsharded table. Rate limiting isn't implemented.

How to fix it:

• Implement rate limiting on authentication endpoints (5 failed login attempts = lockout).
• Add CSRF tokens to forms (prevents cross-site request forgery).
• Implement password requirements (minimum 12 characters, not common patterns).
• Set session timeouts (logout after 1 hour of inactivity).
• Use short-lived tokens for sensitive operations (password reset, email verification).

5. Security Misconfiguration

What it is: Debug mode left on in production. Default credentials not changed. Security headers missing.

How to fix it:

• Never deploy with debug mode on. Never log sensitive data.
• Set security headers: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options.
• Keep dependencies updated. Use tools like Snyk or Dependabot to track vulnerabilities.
• Use environment variables for secrets (API keys, database passwords). Never commit them to git.
• Configure your database to reject connections from the public internet. Only your app server should connect.

6. Vulnerable and Outdated Components

What it is: You're using libraries with known security vulnerabilities. npm packages, pip packages, Ruby gems — all can have bugs that hackers exploit.

How to fix it:

• Run `npm audit`, `pip-audit`, or similar for your stack. Fix high and critical vulnerabilities immediately.
• Set up automated dependency updates (Dependabot, Renovate). Review and merge weekly.
• Minimize dependencies. Each dependency is a potential vulnerability surface.
• Subscribe to security mailing lists for your framework and key dependencies.

7. Authentication and Session Management Failures

What it is: Weak passwords accepted. Session tokens predictable. Password reset links don't expire.

How to fix it:

• Implement multi-factor authentication (MFA) for sensitive operations (admin panel, payment changes).
• Use secure session tokens (random, long, cryptographically generated). Regenerate on login.
• Implement logout properly. Delete the session token server-side, not just client-side.
• Password reset: send time-limited token via email (expires in 1 hour), don't show password change form without verification.

8. Software and Data Integrity Failures

What it is: Unencrypted deployments. Insecure CI/CD pipelines. No integrity checks on data updates.

How to fix it:

• Use HTTPS for all deployments. Verify checksums.
• Implement audit logging: who changed what, when. Essential for compliance.
• Use code signing for releases. Verify signed updates.
• Restrict CI/CD access to trusted developers only.

9. Logging and Monitoring Failures

What it is: You don't know when you're being attacked. No error tracking. No anomaly detection.

How to fix it:

• Log failed authentication attempts (but not passwords).
• Log data access and modifications with timestamps and user info.
• Use Sentry, DataDog, or similar for error tracking. Set alerts on unusual error rates.
• Monitor for unusual activity: multiple failed logins, unusual geographic access, API rate spikes.
• Retain logs for at least 90 days (compliance requirement).

10. Server-Side Request Forgery (SSRF)

What it is: Your server makes requests to URLs specified by user input. An attacker can make your server query internal systems or other user's data.

How to fix it:

• Validate all URLs. Use an allowlist of domains you're allowed to request.
• Don't allow requests to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1).
• Use network-level controls: your app server shouldn't have direct access to internal systems.

GDPR-specific security requirements (UK and EU data)

If you're serving UK/EU customers, GDPR requires you to:

API Security (if you expose an API)

• Authentication: Use OAuth2 or API keys (not username/password). Rotate keys regularly.
• Rate limiting: Prevent abuse. Limit API requests per user per minute (e.g., 100 requests/minute).
• Input validation: Validate all query parameters and request bodies. Reject oversized requests.
• Output encoding: JSON endpoints should set Content-Type: application/json header.
• Versioning: Version your API (/v1/, /v2/). Never break existing API versions without notice.

Deployment Security Checklist

Testing for vulnerabilities

• Dependency scanning: `npm audit`, `pip-audit` (automated, part of CI/CD)
• Static analysis: Linters that catch security issues (eslint-plugin-security, bandit for Python)
• Manual code review: Have someone else review security-sensitive code
• Penetration testing: Before launch, hire a security firm to try to break it (£2K-5K investment)
• Bug bounties: Once launched, offer bounties on HackerOne or Bugcrowd for vulnerabilities

Incident response: What to do if breached

Have a plan before you need it:

1. Contain: If you discover a breach, take the affected system offline immediately.
2. Notify: Contact legal and your security team. Under GDPR, you have 72 hours to notify authorities.
3. Communicate: Notify affected users. Be transparent about what data was accessed.
4. Fix: Understand how the breach occurred and patch it.
5. Document: Log everything. You'll need records for regulatory investigations.

Muhammad Nouman

Founder & Lead Engineer, AyTech Solutions — London, UK