Web security and OWASP — the errors attackers look for

Any web application open to the internet is tested by automated tools and curious people around the clock. Security is therefore not something to think about when the site is finished — it is a way of writing code from the first line. A good guideline is OWASP (Open Worldwide Application Security Project) a non-profit that publishes a widely recognized list OWASP Top 10 of the most critical security risks in web applications. It is not a law but the common starting point the industry speaks from.

§Never trust input from the client

The red thread through almost all web vulnerabilities is trust in data coming from outside. Everything that comes from the browser — form fields, the address bar, parameters, cookies, headers — can be manipulated. An attacker doesn't necessarily use your nice interface; they send data directly to the server. That is why all input must be validated and cleaned on the server before it is used, stored or displayed again. Frontend validation is a help to the honest user, not a defence against the dishonest.

§Broken access control

The most widespread serious error is that access control can be bypassed: a user can see or change something they shouldn't. A classic example is being able to change an ID in the address bar and see someone else's data, because the server doesn't check if the logged-in user actually owns it. The rule is that every single action must be checked on the server to ensure the current user has permission — it's not enough to hide a button in the interface. Assume that anything not explicitly checked is open.

§Injection – when data is read as commands

Injection occurs when data from the user is interpreted as part of a command instead of as pure data. The classic case is a database query, where the user's text is inserted directly into the query, so an attacker can change what the query does. The defence is to separate code from data: use parameterized queries (also called prepared statements), where user input is always treated as a value, never as a command. The same thinking applies everywhere input ends up in a command – it's the principle, not the individual system, you need to understand.

§Cross-site scripting (XSS)

XSS occurs when an attacker's text appears on the page and is run as code in another user's browser — e.g. via a comment that contains a script. The result can be that the attacker steals sessions or acts in the victim's name. The defence is to treat all user content as text when displayed: escape it correctly so characters are displayed as characters and not executed. Use the mechanisms your framework offers for safe printing rather than putting raw text directly on the page.

§OWASP's risk categories — an overview

The list groups recurring risks into categories. You do not need to memorize them, but they are a good checklist basis when you review an application.

§Access codes, sessions and secrets

Never save passwords in plain text. They must be hashed with an algorithm built for the purpose and intentionally slow, and with salt so your password doesn't give the same hash as someone else's. Sessions must be protected so they cannot be stolen or guessed, and a session must be able to expire and be logged out. Access keys, API keys and other secrets never belong in front-end code or version control — they belong on the server, outside what the user can see.

§Safety is a team sport

No single habit makes an application secure. It is the sum: validate on the server control access on every action separate code from data show user content as text keep dependencies updated protect login and secrets and log enough to detect an attack. If you make them spinal cord reactions you close most of the holes OWASP's list warns about — long before an attacker finds them.

“Secure web applications are not built by adding security at the end but by distrusting all input from the first line of code.”

— Common teaching principle in web security