Hey there, this article is going to be challenging. I mean, how do I make web security appear interesting and keep you reading?

So here’s the plan.

I’m thinking maybe the odd meme, and just enough charm to keep you scrolling. All the while striking that balance between actual value and entertainment.

Right…

So… What Is OWASP?

OWASP stands for the Open Worldwide Application Security Project.
It’s a global, non-profit organisation on a mission to make software security understandable, visible, and doable.

Basically, they tell you how not to get hacked. They maintain a bunch of free, open-source resources that help developers (like you and me) build secure web applications.

Solid, community-backed advice. That’s it.

Here’s a link to their website.

OWASP is best known for the OWASP Top 10 — a standard awareness document for developers and anyone working with web application security.
It reflects a broad industry consensus on the most critical security risks facing web applications today.

The list was last updated in 2021, and if you’re building or maintaining web software, it’s basically required reading.

Let’s go through (some of) the list.

A01:2021-Broken Access Control

Access control ensures users can only perform actions or view data they’re authorised for. When it fails, attackers can read, modify, or destroy data — or perform actions well beyond their permissions.

An example?

Imagine a local gym with a new smart booking system. Along comes Joey. He’s a cheapskate, he’s that guy who’s always nipping to the toilet when it’s his turn at the bar.

He discovers that by changing a few characters in the URL of the gym’s booking site — from /bookings/basic-treadmill to /bookings/premium-sauna — he can book the sauna for free.

Good for Joey. Bad for… security.

Here’s some common vulnerabilities:

  • Excessive privileges – Access is granted broadly instead of following "least privilege" or "deny by default" principles.

  • Bypassing checks – Attackers manipulate URLs, form data, or internal state to reach unauthorised functionality (e.g. force browsing).

  • Insecure direct object references (IDOR) – Viewing or editing others' data by guessing or manipulating identifiers.

  • Missing access controls on APIs – Especially for methods like POST, PUT, and DELETE.

  • Privilege escalation – Acting as a user without logging in, or as admin while logged in as a regular user.

  • Metadata tampering – Modifying tokens (e.g. JWTs), cookies, or hidden fields to gain access.

  • CORS (Cross-Origin Resource Sharing) misconfigurations – Allowing unauthorised origins to access APIs.

  • Force browsing – Accessing protected pages or features without proper authentication.

Best Practices:

  • Deny by default, except for public resources.

  • Centralise and reuse access control logic across your app.

  • Enforce ownership checks in domain models — don’t just trust user input.

  • Limit CORS usage and configure it strictly.

  • Remove sensitive files like .git, backups, or directory listings from web roots.

  • Log failed access attempts and alert when appropriate.

  • Rate limit sensitive endpoints to reduce brute-force and automation abuse.

  • Invalidate session tokens properly — use short-lived JWTs, and follow OAuth standards for revocation if tokens live longer.

A02:2021-Cryptographic Failures

Previously known as Sensitive Data Exposure, which is more of a broad symptom rather than a root cause, the focus is on failures related to cryptography (or lack thereof).

Which often lead to exposure of sensitive data.

Here’s some common vulnerabilities:

  • Hard-coded passwords (CWE-259)

  • Broken or weak cryptographic algorithms (CWE-327)

  • Insufficient entropy for randomness (CWE-331)

Here’s some scenarios:

Scenario #1:
An app encrypts credit card numbers in the database, but automatically decrypts them when queried. A SQL injection flaw lets Joey retrieve these numbers in plain text.

Scenario #2:
A website doesn’t enforce TLS everywhere or supports weak encryption. And guess what? Joey is back, he intercepts traffic on an insecure Wi-Fi, downgrades HTTPS to HTTP, steals session cookies, and hijacks user sessions—possibly altering sensitive data like money transfers.

Scenario #3:
Passwords are stored using unsalted or simple hashes. Joey exploits a file upload vulnerability to grab the password database, then cracks the weak hashes using rainbow tables or GPU-powered attacks.

So how’d you protect yourself against this?

First, identify what data requires protection — think passwords, credit cards, health info, personal data, or business secrets. Especially data regulated by laws like GDPR or standards like PCI DSS.

Ask yourself:

  • Is any sensitive data sent or stored in clear text? Check protocols like HTTP, FTP, SMTP, and internal communications too.

  • Are any outdated or weak crypto algorithms or protocols in use?

  • Are cryptographic keys weak, reused, hard-coded, or poorly managed? Are keys accidentally committed to source code?

  • Is encryption consistently enforced? Look for missing security headers or improper TLS certificate validation.

  • Are initialisation vectors (IVs) generated securely and used correctly? Avoid reusing IVs or insecure modes like ECB.

  • Are passwords used as keys without proper derivation functions?

  • Is randomness truly cryptographically secure and properly seeded?

  • Are deprecated hashes like MD5 or SHA1 still around?

  • Are cryptographic error messages or side channels exposing vulnerabilities (e.g., padding oracle attacks)?

Here’s some best practices:

  • Classify your data by sensitivity and legal requirements.

  • Avoid storing sensitive data unnecessarily; discard or tokenize it if possible.

  • Encrypt all sensitive data at rest with strong algorithms.

  • Encrypt all data in transit using modern TLS with forward secrecy and strict security policies like HSTS.

  • Disable caching for sensitive responses.

  • Avoid legacy protocols like FTP or unencrypted SMTP.

  • Store passwords securely using salted, adaptive hash functions such as Argon2, bcrypt, scrypt, or PBKDF2.

  • Use appropriate IVs generated by cryptographically secure PRNGs or nonce-based methods.

  • Prefer authenticated encryption over just encryption.

  • Generate keys securely and handle them as raw byte arrays; if derived from passwords, use proper key derivation functions.

  • Ensure your randomness is truly unpredictable.

  • Regularly review and avoid deprecated cryptographic functions and padding.

  • Verify your configurations independently to catch misconfigurations early.

Oh, and for the record — if you’re not encrypting your passwords, what the hell is actually wrong with you?

A03:2021-Injection

Let’s get straight down to business here. When are applications vulnerable to injection?

  • When user input is not properly validated, filtered, or sanitised.

  • When dynamic queries or non-parameterised calls use unescaped input directly in interpreters.

  • When hostile input manipulates ORM search parameters to extract unauthorised data.

  • When user input is concatenated into SQL queries, commands, or stored procedures without proper safeguards.

Here’s some best practices:

  • Keep data separate from commands/queries.

  • Prefer safe APIs that avoid direct interpreter use and support parameterised queries or ORMs.
    Note: Stored procedures can still be vulnerable if they concatenate data and commands improperly (e.g., using EXECUTE IMMEDIATE).

  • Apply positive server-side input validation, though remember some applications require special characters.

  • For any dynamic queries, escape special characters using interpreter-specific escaping rules.
    Note: User-controlled database structure identifiers (e.g., table/column names) cannot be safely escaped and are risky.

Use SQL controls like LIMIT to restrict the number of records returned and reduce impact if an injection occurs.

Common injection types include SQL, NoSQL, OS command, ORM, LDAP, Expression Language (EL), and OGNL injection — all based on similar interpreter exploitation principles.

More to come….

There’s another 7 to work through.

Stay secure, stay curious, and don’t click suspicious links.

I’ll follow up with the rest in due course, but for now…

P.S - all subscribers are now required to send me your banking information. Don’t ask me why, I don’t make the rules.

But yeah, pop over them, thanks.

Here’s the link.

It’s totally secure.

P.P.S - Actual OWASP website link.