Web Application Security Basics (OWASP Top 10 for Institution Teams)

The most common web application weaknesses explained for small development teams, with the one practical fix that prevents each.

For Developers, student project teams

Most breaches of institutional web apps come from a short list of well-understood mistakes. Here they are, with the single most effective fix for each.

| Weakness | What goes wrong | The fix that matters most |

| --- | --- | --- |

| Broken access control | Users can view or change records that are not theirs by editing an ID in the URL. | Check permissions on the server for every request; never trust the client. |

| Injection | Input is pasted into SQL or commands. | Use parameterised queries / prepared statements everywhere. |

| Weak authentication | Guessable passwords, no MFA, long-lived sessions. | Rate-limit logins, support MFA, expire sessions, hash passwords with bcrypt/argon2. |

| Sensitive data exposure | Data sent or stored unencrypted; secrets in code. | TLS everywhere; secrets in environment configuration, never in the repository. |

| Security misconfiguration | Debug mode on, default credentials, open storage buckets. | A production checklist, reviewed before every deployment. |

| Cross-site scripting (XSS) | User content rendered as HTML runs scripts in other users' browsers. | Escape output by default; use a template engine that does it for you; add a Content Security Policy. |

| Vulnerable components | Old libraries with known holes. | Automated dependency scanning and a monthly update habit. |

| Insufficient logging | Attacks go unnoticed. | Log logins, failures and admin actions; alert on the unusual. |

| Server-side request forgery | The server fetches URLs the user controls. | Allow-list destinations; block internal address ranges. |

| Insecure design | Security considered only at the end. | Threat-model the feature in the planning stage: what could go wrong, for whom. |

Habits that prevent most of this

Code review with a security checklist for every change.
Run a dependency and secret scanner in CI.
Test with a different role than the one you built with.
Get an external penetration test before go-live and after major changes.