OWASP Top 10 2025: Every risk explained

Access control is the code that decides who may read or change what, and it has to run on every request. In our Broken Access Control lesson, a publisher uploads earnings reports before their release time and counts on nobody guessing the URLs. Hiding a resource instead of protecting it is called security through obscurity. A trader guesses the pattern and reads each report early. The 2022 breach of the Australian telecommunications company Optus was the same failure on a larger scale. An unsecured API gave up the passport and driver's license numbers of 9.7 million current and former customers.

Servers, frameworks and cloud services all come with settings, and a setting changed for a quick test can end up in production. In our Cross-Origin Resource Sharing lesson, an engineer at a bank turns off the API's CORS restrictions to debug locally, then commits the change with a TODO note. A recipe blog's hidden script calls the API from a logged-in customer's browser and reads the customer's balance and transactions. Parsers have risky settings too. Even Facebook has suffered from XML External Entities, where an XML parser reads files off the server because a document asked it to.

Every package you install runs with the same access as your own code. In our Slopsquatting (LLM Supply Chain) lesson, an attacker queries LLM coding assistants thousands of times and lists the package names they invent. The attacker publishes one to npm as a working fork of a popular library. Building its reputation takes three months (more patience than most of us have for our own side projects). Someone installs the LLM's suggestion, and the package starts harvesting environment variables in production. In 2020, attackers took over the build system at SolarWinds and hid a backdoor in a security update.

Many websites, banks among them, used to serve most pages over plain HTTP and switch to HTTPS only when the user logged in. Moxie Marlinspike, now better known as the creator of Signal, released a tool called sslstrip. It sits between the user and the site and rewrites the login form's HTTPS links as HTTP. Our SSL Stripping lesson shows how it captures the password while the server still sees a secure connection. Attacks like this one persuaded the web community to serve every page over HTTPS, and your site should do the same.

Injection happens when code builds a command out of text, and part of that text comes from the user. Our SQL Injection lesson attacks a login form whose code pastes the password straight into a SQL query. A single quote in the password field crashes the app, and the logs show a SQL syntax error. Typing ' or 1=1-- as the password then logs you in, because the database reads the password check as always true and ignores the rest of the query. SQL injection has compromised companies as large as Yahoo and Sony.

Some flaws are settled in a planning meeting, long before anyone writes the vulnerable line. In our File Upload Vulnerabilities lesson (based on a real attack), a site checks profile images only in the browser. It publishes each upload, under its original name, at a public URL. An attacker turns off JavaScript and uploads a PHP script — a web shell — as his profile picture. Opening its URL lets him run any command on the server. The fix is a design decision too. Check uploads on the server, rename them and store them where they can never run.

Attackers rarely guess passwords one at a time. They work from username and password lists leaked in earlier breaches, because users often reuse passwords across websites. Replaying those pairs on another site is called credential stuffing. (RockYou's 2009 breach alone leaked 14 million passwords, which became the standard wordlist for attacking logins.) Sessions are the other weak point. In our Session Fixation lesson, a site accepts session IDs in the URL and keeps the same ID after login. The attacker emails a victim a link to a hamster gif with an ID he chose, then reuses it after the victim logs in.

Many web frameworks copy the fields of a request onto an object in one line of code, which saves a lot of typing. In our Mass Assignment lesson, a profile page lets users change their email and password, but the server copies every field it receives onto the User object. An attacker adds one extra field to the request and makes himself an administrator. Version 3.0 of Ruby on Rails was open to the same attack, and a hacker (thankfully a white hat) used it to get administrator access to GitHub.

Many attacks leave a trail in your logs before they succeed. In our SQL Injection lesson, the attacker's first probe, a stray quote in the password field, crashes the app and writes a SQL syntax error to the log. If that error raises no alert, a later attempt logs the attacker in and nobody notices. Our Logging and Monitoring lesson covers what to record and how to collect logs on a central server. It also shows how to set alert thresholds that catch suspicious errors without getting your team out of bed every night.

When a request fails halfway, your code has to decide what to tell the user and whether to let the request through. In our XML External Entities lesson, an attacker sends XML that pulls the server's password file into the document. The parse fails, as it should. The error message, however, includes the whole expanded document, password file and all. Our Information Leakage lesson recommends a generic HTTP 500 page for users, with stack traces and other details kept in your server-side logs.