OWASP Top 10

The most common web-application flaw. About whether the website properly enforces who can do what once someone's logged in.

What to do:
• Ask your developer for the access-control matrix: who can see and do what.
• Run the “different user” test: log in as a regular customer, try /admin or other customers' data.
• For anything handling money or personal data, have an external pen test before launch and annually after.

Two things: data sent over the internet, and data stored on disk. Classic failures: HTTPS not enforced everywhere, passwords stored as plain text, sensitive data sat unencrypted in a database.

What to do:
• Test your site's TLS with SSL Labs. Aim for an A grade.
• Ask your developer: “Show me how passwords are stored.” If they can decrypt them, the design is wrong.
• Don't keep what you don't need. Delete old customer records on a schedule.

The classic web flaw and still common: user-typed input passed directly to a database or system command.

What to do:
• Insist that parameterised queries (or the framework's ORM) are used everywhere.
• Run a free automated scan with OWASP ZAP.
• For business-critical applications, pay for a penetration test.

Some flaws can't be patched — they're built into the design. A password-reset flow with no rate limiting. A checkout that trusts the price the browser sends.

What to do:
• For new applications, ask: “What did you think about misuse before features?”
• Run a five-minute “what would I try as an attacker?” exercise.
• Add rate limiting on failed logins, password resets, account creation, contact forms.

Default passwords. Admin interfaces facing the internet. Verbose error messages. Cloud storage buckets accidentally public.

What to do:
• Run Security Headers on your site. Aim for B+.
• Check admin paths (/admin, /wp-admin, /phpmyadmin). Restrict by IP or VPN.
• For cloud users, use Defender for Cloud / AWS Trusted Advisor / Google SCC.

Most websites are built from many bits — CMS, plugins, libraries. If anything's out of date, the website inherits the holes.

What to do:
• For WordPress: use a managed WP host (WP Engine, Kinsta, SiteGround) that handles patching.
• Ask your developer for an SBOM: which libraries and what version.
• Set a monthly calendar reminder: review and apply CMS / plugin / library updates.

Classic mistakes: no rate limiting on failed logins, predictable password resets, sessions that never expire, no MFA.

What to do:
• Use a recognised authentication provider (Auth0, Microsoft Entra ID, AWS Cognito, Okta, Clerk).
• Enforce MFA for any account handling money or personal data.
• Set sensible password rules (long over complex), use modern hashing (bcrypt/argon2), rate-limit attempts.

How modern software updates itself. Auto-updates from untrusted sources or unverified library pulls can be poisoned.

What to do:
• Pin third-party library versions; don't auto-pull the latest.
• Limit who can deploy code. Two-person review on production deploys.
• If you write code, sign your releases. If you don't, ask vendors how they sign theirs.

Average detection time is around 200 days. Usually because nobody was watching.

What to do:
• Log authentication, admin actions, and errors. Send logs off the server.
• Set basic alerts: failed-login bursts, new admin users, bulk data exports.
• For serious sites, a managed monitoring service should be watching out of hours.

Some websites let users provide a URL. If the website blindly fetches that URL, an attacker can provide an internal URL and pull private data.

What to do:
• Block server-side requests to internal IP ranges (10.x, 172.16–31.x, 192.168.x, 169.254.x).
• On AWS, ensure IMDSv2 is required. Equivalents on Azure and GCP.
• Where possible, allowlist external destinations.