Security Testing

Learning security testing gives you the ability to protect user data and maintain trust in applications by finding and fixing dangerous weaknesses before attackers can use them. This skill is essential for working on modern production systems, including AI-powered products, where a single error can expose private information or allow unauthorized access. It prepares you to implement continuous checks into your daily development workflow and to specifically test AI systems against risks such as prompt injection—where a user tricks an AI into revealing restricted information—and data leakage, which is the accidental exposure of sensitive details that should remain hidden.

Security testing is the practice of deliberately trying to break an application to find weaknesses that attackers could also exploit. Instead of just checking that the software works for normal users, you put on an 'attacker's hat' and ask, 'How could I misuse this? How could I get data I shouldn't see? How could I make the system do something it wasn't designed to do?' The four main types of vulnerabilities are injection, broken authorisation, exposed secrets, and vulnerable dependencies. Injection occurs when untrusted user input is interpreted as part of a command or query, like when a text field meant for a username can delete a whole database. Broken authorisation means a normal user can access a different user's account or an admin-only function. Exposed secrets are things like passwords, API keys, or database credentials that accidentally appear in public code or responses. Vulnerable dependencies are third-party libraries that have known security flaws. You usually start with automated scanners that look for known patterns, but the library notes and the book Full Stack Testing emphasise that scanners only catch known issues — a human tester is needed to find logic flaws, the kind of mistakes in the way the application decides what to allow and what to reject. Security testing is not a one-time activity; it should happen continuously, and dependency scanning belongs in your pipeline on every build so that newly discovered vulnerabilities are caught immediately.

Imagine you are a security guard in a large office building. Your job is to check every door and window to see if it can be opened from outside without a key. You start by looking at the obvious points: the front door, the fire exit, and any ground-floor windows. That is like running an automated scanner — you check known weak points. But the building has an open courtyard, and you notice that a third-floor window is slightly ajar and reachable from a tree branch. That is the kind of thing a scanner might not know to check. A human tester notices unusual combinations and tries them. In the building, you might also check whether the security system gives different alarms to different people — maybe a cleaner's badge opens the financial records room. That is authorisation testing. You are also looking for 'secrets' — maybe someone left a spare key under the doormat. In software, that is an exposed API key. And you might check whether a recently replaced door lock still uses an old, known-broken model — that is a vulnerable dependency. The analogy holds until you imagine that a security expert can only do this once at the end of the project. In reality, you keep checking the building every time a new room is added or a lock is changed, because a new vulnerability can appear with any change.

Security testing is the process of actively probing an application to identify and exploit its weaknesses, focusing on injection, broken authorisation, exposed secrets, and vulnerable dependencies, using a combination of automated scans and human-driven exploration.

This concept connects strongly to API Testing, which involves checking permissions on endpoints, where an endpoint is a specific URL or address that the software uses to receive requests. It also relates to Exploratory Testing, a method explained in Full Stack Testing that provides the investigative mindset needed to find logic flaws that automated tools miss. The principle of Shift-Left Testing argues that you should move security checks into the early stages of development rather than waiting until the end, while equivalence partitioning and boundary analysis help you test specific inputs like maximum allowed values. Contract Testing ensures that different parts of a system agree on their communication rules, which is crucial for securing authentication (verifying who a user is) and authorisation (determining what they can do). These activities work alongside threat modelling, which identifies potential attacks before testing begins.