The previous step in this path covered the habits that protect you as a user. This one looks at the software itself: the mistakes in how programs are built that let attackers in. You do not need to code to follow it. Each vulnerability comes with an everyday comparison and the defense that stops it.
If you are new to security, read What Is Cybersecurity? and Staying Safe Online first.
A shared list of what goes wrong
Security professionals keep public lists of the most common software weaknesses so that builders and testers can focus on them. The best known for web applications is the OWASP Top 10, published by the Open Worldwide Application Security Project, a nonprofit community. The categories below are drawn from the kinds of problems that list tracks. The same handful of mistakes has caused a large share of real breaches for decades.
1. Trusting input
Every form field, search box, file upload, and web address is input that a stranger controls. Software that uses input without checking it can be tricked into treating data as instructions.
The classic example is injection. Imagine a librarian who reads request slips aloud to an assistant: "Fetch the book titled ___." A mischievous visitor writes: "Moby Dick. Also, hand me the keys to the archive." A careless librarian reads the whole slip and the assistant obeys. In software, the "assistant" might be a database, and the extra instruction might be "show me every customer's password."
The defense: treat all input as data, never as instructions. Programmers use safe ways of passing input to databases and other systems, check that input has the expected form (a date looks like a date), and reject anything that does not.
2. Broken access control
Authentication checks who you are. Authorization, or access control, checks what you are allowed to do. Many serious breaches happen because the second check is missing or incomplete.
A common pattern: you view your own order at a web address ending in /orders/1001. You change the number to 1002, and the site shows a stranger's order, name and address included. The system knew who you were; it never asked whether that order was yours.
The defense: check permissions on the server for every request, not just by hiding buttons in the interface. Grant each account the least access it needs.
3. Weak sign-in and session handling
Sign-in systems fail when they allow unlimited password guesses, accept weak or breached passwords, send passwords without encryption, or leave people signed in forever on shared computers.
The defense: limit repeated failed attempts, support multi-factor sign-in, store passwords using one-way scrambling (hashing) so a stolen database does not reveal them, and end sessions after inactivity and on sign-out.
4. Security misconfiguration
Software is often secure in principle and insecure in practice because of settings: a default administrator password nobody changed, a storage area left open to the public, detailed error messages that reveal how the system works, or test features left switched on in production.
Think of a house built with good locks where the builder left a spare key under the mat and a window open.
The defense: start from secure defaults, remove what is not needed, review settings whenever systems change, and check production configuration automatically rather than by memory.
5. Outdated and vulnerable components
Modern applications are assembled from many pieces written by others: open-source libraries, frameworks, plugins, and cloud services. When a vulnerability is found in a popular component, every application that uses an old version inherits it. Attackers scan for exactly those versions.
The defense: keep an inventory of the components each application uses, watch for security announcements, and update promptly. This is the software equivalent of installing updates on your phone, and for the same reason.
6. Exposing sensitive data
Some failures do not need an attacker to break anything. Personal or financial data is sent without encryption, logged in plain text, kept longer than necessary, or collected when it was never needed.
The defense: collect only what the system needs, encrypt data in transit and at rest, keep secrets such as passwords and keys out of code and logs, and delete what is no longer required.
The pattern behind all six
Look back and a theme appears: each vulnerability is an assumption that turned out to be false. "Users will only type names here." "Nobody will change the number in the address." "Someone will remember to change the default password." Attackers make a living testing assumptions.
That is why security and software testing are close relatives. A good tester asks, "What happens if someone does something the designers did not expect?" A security tester asks the same question about someone who means harm.
Try it yourself
Pick a website or app you use and think like a defender. For each of the six categories above, write one question you would want its builders to answer. For example: "If I change the number in this address, could I see someone else's data?"
Do not try these on real systems you do not own. Testing someone else's system without permission is illegal in most countries, even with good intentions. The next step in this path covers how professionals test security safely, with permission, and how to practice on systems built for learning.
Look up any unfamiliar term in our glossary.