Security Testing

Learning security testing gives you the skills to find and fix the most common and dangerous vulnerabilities in applications before attackers can exploit them. It unlocks your ability to work on real-world production systems, including AI-powered products, where a single security flaw can compromise user data and trust. It builds the foundation for advanced topics like threat modelling, penetration testing, and secure software design, and it prepares you to implement security checks in CI/CD pipelines and to test AI systems for issues like prompt injection and data leakage.

Security testing is the practice of deliberately trying to break an application in order 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 means untrusted user input gets 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. The library notes say this is a full-stack skill: the same tester covers functional, visual, performance, accessibility and security layers, and it complements threat modelling rather than replacing it.

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 is your first concept in the Software Testing area, but it connects strongly to many topics you will meet later. API Testing will involve checking authorisation on endpoints, which is a core part of security. Exploratory Testing, as explained in Full Stack Testing, is exactly the mindset you need to find logic flaws that scanners miss. Shift-Left Testing argues that you should move security testing into the early stages of development and keep it running in the pipeline. The principle of equivalence partitioning and boundary analysis in the parent Software Testing concept also applies here — you test the edges, like the maximum allowed input length or the boundary of a numeric range. And Contract Testing, which checks that a provider and consumer agree on their interface, is especially relevant to security because authentication and authorisation are a key part of that contract. Your library notes that security testing complements threat modelling — threat modelling decides what could be attacked, and security testing verifies whether those attacks actually succeed.