Security Testing Fundamentals

Why it matters

A functional defect usually costs one user one task. A security defect can expose every user's data at once, and the attacker who finds it does not file a bug report. The cost arrives later, as a breach, a regulatory fine, lost customers and an emergency fix under pressure, and it is usually far higher than the cost of the test that would have found the weakness.

For a tester, security is where the ordinary habits pay most: thinking in negative cases, reading a requirement for what it forbids, questioning what the system assumes. Many security defects are ordinary defects, a missing check, a wrong default, a verbose error message, that a tester who knows what to look for finds without special tools. This lesson gives the vocabulary and the ground rules; the following lessons start with the OWASP Top 10 and then take the main areas, authentication, sessions, access control, injection and more, one at a time.

What security protects: confidentiality, integrity, availability

Security requirements are easier to test once you name which of three properties each one protects. Confidentiality: information is visible only to those authorised to see it. Integrity: data and functions change only through authorised actors and authorised paths, and changes can be traced. Availability: the service is there, with acceptable performance, when legitimate users need it. Security people call these the CIA triad. ISO/IEC 25010:2023 lists confidentiality and integrity among the sub-characteristics of security, next to non-repudiation, accountability, authenticity and resistance (staying in operation while under attack), and files availability under reliability, which is why availability tests often sit with the performance work.

Each property suggests its own test questions, and the expected result of a security test is often that nothing happens: the request is refused, the data is unchanged, the service keeps serving.

• Confidentiality: can a logged-out visitor, another employee or a lower role read the salary slip? Does the slip leak through a URL, a log, a cache or an error message?
• Integrity: can the bank account be changed without re-authentication, by a tampered request or by a replayed one? Is every change recorded with who and when?
• Availability: what happens to the login page under a burst of failed attempts, or when a 50 MB file is sent to the "query my slip" form? Does one user's abuse slow everyone down?

Threats, vulnerabilities, attacks and risk

Five words carry most security conversations, and testers mix them up. An asset is something worth protecting: salary data, the payroll run, the company's reputation. A threat is a potential cause of harm to an asset, usually named with its actor: a disgruntled employee, a criminal group, an automated bot, an honest administrator making a mistake. A vulnerability is a weakness a threat could use: a missing authorisation check, an outdated library, a password reset link that never expires, a backup left in a public folder. An attack is an attempt to use a vulnerability against an asset, and an exploit is the technique or code that does it. Risk combines how likely a successful attack is with how much damage it would do, the same likelihood-and-impact reasoning as in risk-based testing.

The division of labour follows. Testers cannot remove threats; the bots exist whether or not the portal is weak. Testers find vulnerabilities before an attacker does and report them with enough evidence for the team to judge the risk. A short note like the one below, written when a feature starts, turns a vague worry into test conditions:

Asset:          Salary slips (PDF)
Threat:         An employee reads a colleague's slip
Vulnerability:  Slip URL uses a guessable id and no ownership check
Test condition: GET another user's slip id with my session -> 403 or 404, no slip

Asset:          Bank account number for salary
Threat:         Attacker with a stolen session redirects a salary
Vulnerability:  Change saved without re-authentication or notice
Test condition: Change the account -> re-auth prompt, notice sent, audit record

Asset:          Employee accounts
Threat:         A bot tries leaked passwords
Vulnerability:  No rate limit; error text reveals whether a username exists
Test condition: Burst of failures -> lockout or delay; same message for any user

Try it: Test Scenario Generator Try it: Negative Test Generator

Four ways to look: SAST, DAST, vulnerability scanning and penetration testing

Security testing uses several approaches that look at the system from different sides. Each finds weaknesses the others miss, so mature teams combine them, and a tester should know which one found what.

• Static application security testing (SAST) analyses source or compiled code without running it, like a reviewer reading every line. It finds code-level weaknesses early, a SQL query built by string concatenation, a hard-coded secret, and points to the file and line. It runs in the developer's editor (IDE) and the CI pipeline, often reports findings that turn out to be false positives, and cannot see runtime configuration or how components are deployed.
• Dynamic application security testing (DAST) tests the running application from outside, as a user or attacker would, sending requests and inspecting responses. The name usually refers to automated tools that crawl the application and send attack-like requests, but the principle is the same when a tester does it by hand. It finds what is actually exposed: a missing security header, a session cookie without HttpOnly, an input that reflects script, an endpoint that answers without a token. It needs a deployed test environment and test accounts, misses code it cannot reach, and cannot say which line to fix. Most of what a QA tester does by hand in a browser or an API client is dynamic testing in this sense.
• Vulnerability scanning checks what is installed and exposed, servers, frameworks, libraries, open ports, TLS settings, against known vulnerabilities and common misconfigurations. Known vulnerabilities are published with CVE (Common Vulnerabilities and Exposures) identifiers, such as CVE-2021-44228 for the Log4j flaw called Log4Shell; software composition analysis (SCA) does the same matching for an application's dependencies. Scanning is fast, broad and repeatable, a good pipeline gate, but it knows only weaknesses that are already known and nothing about your business logic.
• Penetration testing is a human-led, authorised simulation of an attack within an agreed scope and time. The tester chains findings, a verbose error plus a weak password policy, to show what an attacker could actually reach. NIST SP 800-115 describes it in four phases: planning, discovery, attack and reporting. It gives the strongest evidence and the deepest coverage of one system at one moment, costs the most, and so is often scheduled before a major release or once a year.

The rule: test only with written authorisation

A security test sends the same requests an attacker would. What separates testing from attacking is permission, not intent: in many countries, accessing a computer system without authorisation is a criminal offence even when nothing is damaged and the aim was to report the weakness. "I was only testing" does not make the access authorised. So the rule is absolute: test only systems you own or have written permission to test, and only within the scope that permission describes.

Written permission in practice is a short rules-of-engagement note agreed before the first request. For your own team's test environment it may be the test plan with its security scope signed off by the product owner; for production, a third-party service or a client's system it is an explicit document. A bug bounty programme's published policy counts as written authorisation, but only for the targets, techniques and conduct it lists.

• Use test environments and test accounts you created; never make a real customer's data the victim of a test.
• Use benign payloads that reveal handling without damage: a single quote ' or <b> shows whether input is escaped; nothing needs to be deleted to prove a point.
• Stop and report when you reach data you should not see, and keep findings in a restricted ticket without screenshots of real personal data. Going further is the penetration tester's job under their own authorisation.

Rules of engagement: payroll portal, release 4.2 security pass
Authorised by:  Head of HR Systems (product owner), 2026-10-04
Targets:        https://payroll-test.example only (test environment)
Out of scope:   production, the payment provider, the SMS gateway, staff laptops
Accounts:       test users EMP-1001, EMP-1002, HR-ADMIN-01 (test data only)
Allowed:        manual checks, header, cookie and auth checks, benign payloads
Not allowed:    denial of service, password guessing across many accounts,
                social engineering, copying any real employee data if encountered
Window:         2026-10-05 to 2026-10-08, 08:00 to 18:00 Riyadh time
Contacts:       QA lead (findings), platform on-call (if something breaks)
Findings:       restricted ticket in the tracker, no screenshots of real data

Worked example: a first security pass on the payroll login

The rules of engagement above are signed; you have the test environment, three test accounts and an afternoon. A first pass does not try to break in. It checks the baseline controls one property at a time and records evidence.

• Confidentiality: log in as EMP-1001, open your slip, note the URL /slips/48213.pdf, then request /slips/48214.pdf, the slip of your other test account EMP-1002. Expected: 403 or 404 and no slip; record the status, not the content. Repeat without a session: expected 401 or a redirect to the login page.
• Session and configuration: paste the login response headers into the Cookie Analyzer and the Security Header Analyzer. Expected: the session cookie carries Secure, HttpOnly and a SameSite value, and Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff and frame protection (X-Frame-Options or the CSP frame-ancestors directive) are present; together these headers tell the browser to use HTTPS only, limit where scripts may load from, not guess content types and not show the page inside another site's frame. Each missing item is a finding with the exact response attached.
• Integrity: as EMP-1001, change the bank account. Expected: the portal asks for the password or a one-time code again, notifies the employee and writes an audit record. Then check that nobody else can make this change: send the same change request for EMP-1001's account with EMP-1002's token, from an API client or the API Authentication Tester. Expected: 403 or 404, and EMP-1001's account unchanged when you look again. The tool assumes the token you enter should be accepted, so it flags this rejection as a failure; here the rejection is exactly the result you want, and its rows without a usable token should get 401.
• Authentication and availability: enter a wrong password for EMP-1002 fifteen times. Expected: lockout or a growing delay after the agreed number of attempts, and the same error text for a wrong password and a non-existent user, so the login does not reveal which usernames exist. Meanwhile EMP-1001 can still log in normally: one account's failures must not lock everyone out.

Try it: Security Header Analyzer Try it: Cookie Analyzer Try it: API Authentication Tester

Frequently asked questions

References

• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• NIST SP 800-115: Technical Guide to Information Security Testing and AssessmentNIST · 2008How to plan and run security assessments: review, target identification, vulnerability validation and reporting.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023The product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.