Web Application Security

Introduction

Most websites accept input from strangers: a search box, a login form, a comment. If the code trusts that input, attackers can abuse it. The OWASP Top 10 is a respected list of the most serious web application risks. This lesson is for defenders and developers. Only test systems you own or have written permission to test.

The simple explanation

Never trust input. Treat everything from the user as data, never as code or commands, and check what each user is allowed to do on the server.

Injection (SQL injection)

If a program builds a database command by joining strings, attacker input can change the command. A vulnerable pattern, shown for learning:

# DANGEROUS: user input is pasted into the SQL text
query = "SELECT * FROM users WHERE name = '" + name + "'"

If name is ' OR '1'='1, the query returns every user. Worse inputs can read or destroy data.

The fix is parameterised queries (prepared statements). The input is sent separately from the command, so it can never be interpreted as SQL:

cursor.execute("SELECT * FROM users WHERE name = ?", (name,))

Also use accounts with minimal database privileges, and validate input.

Cross-site scripting (XSS)

XSS happens when a site shows untrusted input in a page without making it safe. An attacker's script then runs in other users' browsers and can steal sessions or change the page.

Defences:

• Escape or encode output according to where it is placed (HTML, attribute, URL). Modern frameworks such as React do this by default. Be careful with features that insert raw HTML.
• Sanitise any HTML you must allow, with a well-known library.
• Use a Content Security Policy header to limit which scripts can run.
• Mark session cookies HttpOnly so scripts cannot read them.

Broken access control

This is when a user can do something they should not, for example changing a number in a URL to see someone else's order:

/orders/1042      <- my order
/orders/1043      <- someone else's order, but the server did not check

Defences: check permissions on the server for every request. Never rely on hidden buttons or client-side checks. Deny by default, and test with different user roles.

Cross-site request forgery (CSRF)

A malicious page can make your browser send a request to a site where you are logged in. Defences include anti-CSRF tokens and SameSite cookies.

Other essentials

• HTTPS everywhere for all traffic
• Keep dependencies updated. Vulnerable libraries are a major cause of breaches.
• Do not show detailed errors to users, and log them privately.
• Rate limit and monitor login and sensitive endpoints.
• Security headers and secure cookie settings.

Try it yourself

Open the OWASP Top 10 and pick three items. For each, write one sentence describing the risk and one defence. Then review a small form in a project of yours and ask: where does user input go?

Summary

• Treat all input as untrusted data. Use parameterised queries to stop injection.
• Escape output to prevent XSS, and check authorisation on the server for every request.
• Use the OWASP Top 10 and cheat sheets as a checklist, and keep dependencies updated.