Common Vulnerabilities

The main web vulnerabilities

SQL injection happens when user input is joined into a database query, so the input is interpreted as SQL. An attacker can read or change data they should not reach. Use parameterised queries (prepared statements), which keep data separate from the query text.

Unsafe:  "SELECT * FROM users WHERE name = '" + name + "'"
Input:   name = ' OR '1'='1
Result:  SELECT * FROM users WHERE name = '' OR '1'='1'    -- condition is always true, every row is returned

Safe:    "SELECT * FROM users WHERE name = ?"   with name passed as a parameter
         The whole input is treated as a name to look for, so it matches nothing.

The same trick can bypass a login check, and with more elaborate input an attacker can read other tables, change or delete data, or in some setups run commands on the database server.

Cross-site scripting (XSS) happens when untrusted input is placed into a web page without encoding, so the browser runs an attacker’s script in the context of your site. Encode output for its context, use a framework that escapes by default, and add a Content Security Policy as a second layer.

Cross-site request forgery (CSRF) happens when another site tricks a logged-in user’s browser into sending a request your site accepts. Defend with anti-forgery tokens and SameSite cookies.

Broken access control means users can reach data or actions that should be off limits, for example by changing an ID in a URL. Check permissions on the server for every request (see Authentication vs Authorization).

The idea behind SQL injection applies to operating system commands, LDAP, templates and more: never build commands by joining strings with untrusted data.

Other risks to recognise

• Sensitive data exposure and weak cryptography: missing HTTPS, home-made encryption, passwords stored badly (see Password Security).
• Security misconfiguration: default passwords, open debug pages, overly broad permissions.
• Vulnerable components: outdated libraries with known flaws (see Dependency Risks).

How the defences fit together

Most of these come down to the same habits: treat input as untrusted and validate it, encode output, use safe APIs instead of string building, grant least privilege, and keep software patched. The OWASP Top 10 is a regularly updated list of the most critical web application risks, and the place to start reading.

Try it

Read the SQL injection example in the OWASP cheat sheet. Then open a project you know and search for places where SQL, shell commands or HTML are built by joining strings with variables. Could any of that input come from a user?