Speed has become a defining priority in modern software development.
Agile practices have already shortened the cycle between planning and delivery, and AI is now accelerating the remaining stages of the software development life cycle (SDLC), including requirements, implementation, validation, and release.
As a result, features that once took an entire quarter to deliver can now reach production within a matter of weeks.
Attackers have become faster as well. The same tools that accelerate software delivery can also speed up reconnaissance, payload generation, and the identification of exploitable weaknesses.
They do not operate on the same release schedule as development teams, which means the gap can grow from both sides.
At the same time, security reviews have largely remained unchanged. Many still take the form of scheduled engagements, planned and scoped weeks after the decisions that introduced the vulnerability have already been made.
QA teams are already closing part of that gap and AI can make their daily testing work even more effective. Basic checks and validations such as ensuring that forms reject oversized input, password fields are properly masked, and payment traffic uses HTTPS are already part of the standard testing processes.
Additionally, with AI, testers can also analyze code and turn technical findings into clear, human-readable explanations, making it easier for developers, testers, and other stakeholders to understand potential issues.
AI can also assist with testing running applications, helping teams identify unexpected behavior and validate whether an application works as intended.
Nowadays, the difference is not necessarily in what the tools we are using, but the questions the team is asking. Testing by accident covers whatever the happy path touches. Testing on purpose covers what an attacker tries first: the role field in a registration payload, the price in a client-side request, the file that claims to be a PDF and is not.
None of this requires a new headcount or a new budget line. It requires the QA team to ask a second question after the first one passes.
Does the field reject oversized input, and does it reject a script tag. Does the login work, and does it still work when the token belongs to someone else. Does the upload accept a PDF, and does it accept an executable renamed to look like one. Ten of those second questions cover most of what goes wrong.
Each practice below is a ‘second question’, and they follow a request through the application in order – what the client sends, who the application thinks is sending it, what it sends back, and how it behaves when something goes wrong. The example scenarios are written to slot into an existing test plan rather than a separate security pass.
The security practices I recommend for QA teams to explore are:
1
Validate every input on the server, not just in the browser
2
Change the values the interface will not let you change
3
Test authentication past the login screen
4
Follow the session through logout, expiry, and a second browser
5
Try to reach another user’s data by changing one number
6
Treat every endpoint as unauthenticated until proven otherwise
7
Check what leaves the application, not just what enters it
8
Break the application on purpose and read what it tells you
9
Upload the file the application should refuse
10
Confirm the security headers are present and configured
Work through them in order the first time. After that, treat them as a checklist to run against any feature touching authentication, user data, or file handling – which in most applications is most features.
1. Input validation testing: validate every input on the server, not just in the browser
Input validation is the practice most QA teams already cover and the one most often verified in the wrong place. A field that rejects a script tag in the browser has proven the browser rejects it. It has not proven the server does.
The test that matters bypasses the interface entirely. Send the payload directly to the API and see whether the application still refuses it. If the browser blocks the input and the endpoint accepts it, the validation is cosmetic.
Coverage should include the common injection classes – cross-site scripting (XSS), where injected script executes in another user’s browser, and SQL injection, where input reaches the database as executable syntax – along with boundary conditions: maximum field length, unexpected data types, and empty or null values in required fields.
Examples of testing scenarios:
Invalid input validation – Confirm the application handles unexpected input types correctly (for example, entering letters in a credit card number field).
SQL Injection validation – Verify that the web application properly validates and sanitizes user input and does not execute malicious SQL statements.
Enter a common SQL injection payload (‘ OR ‘1’=’1) into the ‘Search products’ text input field and verify that the web app validates the user input without executing any malicious SQL statement.
Maximum length of characters – Verify if the web app displays proper error message in case when the user tries to submit an oversized input through API call for the Full Name field.
2. Client-side trust testing: change the values the interface will not let you change
Practice 1 asks whether the server checks what you send. This one asks what happens when you send something the interface was never designed to produce.
Read-only attributes, disabled select elements, hidden inputs, and maxlength constraints are enforced in the DOM. They are rendering instructions, not authorisation controls, and they hold only for a client that chooses to honour them.
Any request constructed outside the browser – or inside it, after the DOM has been edited – carries whatever values the sender assigns.
Browser DevTools covers most of this without additional tooling. Modify the value in the request payload before it is sent, or edit the element and submit through the interface. If the server persists the manipulated value, it is trusting client-side validation, and that trust is trivially bypassed.
The consequences are not abstract.
A user who can set their own role becomes an administrator. A user who can set their own price buys at whatever number they choose. A user who can edit a read-only balance field decides what they are owed.In each case the server has delegated a security decision to input it does not control.
Example for testing scenarios:
User permission, Price manipulation – Using the DevTools, verify that a regular logged-in user will not be able manipulate the prices of the items in the web shop
User permission, Read-only field submission – Verify that any user will not be able to update the Account balance (read-only) field using the DevTools from the Browser.
3. Authentication testing: test authentication past the login screen
Password complexity rules and multi-factor authentication (MFA) are the components with visible interfaces and explicit acceptance criteria, which is why they get QA-tested.
During the testing performed regarding this point, the QA team must ensure that the user will not be able to create an account if the criteria for strong password is not fulfilled. But the components that also get exploited are the ones without an interface: password reset, account recovery, and the intermediate state between credential submission and a fully authenticated session.
A password reset flow is an authentication bypass with a legitimate purpose. It issues a bearer credential over an out-of-band channel, accepts that credential back, and establishes a session without the user demonstrating knowledge of the previous password.
Four properties of that token determine whether the flow is sound: it must be single-use, time-bound, cryptographically unpredictable, and bound to exactly one account. Testing should verify each independently.
The reset request endpoint also determines whether the application leaks account existence. If a request for a registered address returns a different response body, status code, or response latency than a request for an unregistered one, the endpoint is a user enumeration oracle regardless of what the reset flow itself does.
MFA requires the same treatment. Verifying that the second factor is required is not the same as verifying it cannot be skipped. If the application issues a session token at the password step and only checks the second factor client-side, or accepts that pre-MFA token at protected endpoints, the second factor is decorative.
Examples of some testing scenarios:
Password complexity – Verify that the user will not be able to create an account or to reset a password if a weak password is provided during these flows.
MFA – Verify that MFA is required after successful primary authentication.
Reset token expiry – Request a reset token, wait past the stated validity window, and submit it. Confirm rejection rather than acceptance with a warning.
4. Session management testing: follow the session through logout, expiry, and refresh
Session management testing verifies that a session token behaves like the credential it is – securely generated, transmitted only over TLS, and revoked when it should be.
Server-side invalidation is the property worth testing hardest. Most logout implementations clear local storage or delete a cookie, which removes the client’s copy and nothing else. If the captured token still authenticates a request after logout, the session was never terminated.
Storage and transmission determine whether the token can be stolen at all. Session cookies require HttpOnly, Secure, and an appropriate SameSite value. A session identifier in localStorage is readable by any script executing in the page, which turns every cross-site scripting finding into a session hijacking finding.
Examples of testing scenarios:
Token invalidation – Verify that the session token will be invalidated on logout
Capture the session token, log out through the interface, then replay a request with the captured token. Confirm that the server rejects it rather than accepting it because the client no longer holds a copy.
Token expiration – Verify that the user token will expire properly and the users will not face any errors upon token refresh/exchange
5. Broken access control testing: try to reach another user’s data by changing one number
Access control is the only class in this list where the application behaves correctly for every user acting in good faith and fails entirely for one acting deliberately. Nothing surfaces in the interface, which is why it needs testing from a second account rather than a second role menu.
Two directions matter.
Vertical escalation, where a lower-privileged user reaches functionality reserved for a higher-privileged role.
Horizontal escalation, where a user reaches another user’s records at the same privilege level.
The second is more common and less often tested, because it requires a second account and a known object identifier.
Enforcement has to be per-request and server-side. An interface that hides the admin navigation from standard users has hidden a link, not protected an endpoint.
Example scenarios:
Vertical escalation. Authenticated as a standard user authorised only to browse, purchase, and review products, request the order management endpoints directly. Confirm the server returns 403 rather than rendering the section.
Insecure Direct Object Reference (IDOR). Authenticated as user1, change /user-profile/001/ to /user-profile/002/. Confirm the server checks ownership rather than returning the record because the identifier is valid.
6. API security testing: treat every endpoint as unauthenticated until proven otherwise
Your APIs should be treated as a critical line of defence and secured as thoroughly as possible. QA teams can use tools such as Postman or Burp Suite to verify that protected APIs remain inaccessible when authentication tokens are removed, modified, or replaced – the goal is to construct requests the client would never send and confirm the API refuses them.
Authentication and authorisation are separate checks. Removing the token tests whether the endpoint is protected at all. Substituting another user’s valid token tests whether the endpoint checks that the token holder owns the resource, which is Broken Object-Level Authorization (BOLA).
Rate limiting is the third property, and it is usually applied to login and registration and nowhere else. Endpoints that create records, trigger email, or perform destructive administrative actions are worth checking specifically.
Examples of testing scenarios:
Rate limiting – Verify that the system will not allow more than X login attempts in one minute
Successful login – Verify that the user will be able to successfully login only after providing all the required user details (Username, Password, MFA); additionally, verify that sensitive user’s data will not be stored locally.
7. Sensitive data exposure testing: check what leaves the application, not just what enters it
Any information that contains sensitive user data, such as login credentials, payment details, or secrets included in URLs, must always be returned in an encrypted format. Failing to encrypt this data can expose it to unauthorized individuals, increasing the risk of theft, misuse, and unauthorized access.
Any instance of unencrypted sensitive data should be reported as a high-severity security issue and resolved before the application is released.
This practice covers three distinct requirements that are easy to conflate. Sensitive data must be transmitted over TLS, must not appear in locations that persist outside the encrypted channel, and must not be rendered in plaintext where it can be observed.
The second is where implementations fail. TLS protects a URL in transit, but the URL itself is written to browser history, server access logs, and the Referer header sent to third-party resources. A reset token or session identifier in a query string is exposed in all three regardless of the transport.
Rendering is the third. Password and payment fields should be masked by default, and API responses should omit fields the client does not need rather than returning them for the interface to hide.
Examples of testing scenarios:
Client-side storage – Verify that sensitive user data (Authentication tokens, Passwords, Personal information, Financial information …) will not be stored locally in the user’s browser (in the localStorage, sessionStorage, Cookies, IndexedDB …)
Profile/Account Management – Verify that sensitive profile actions, such as changing the password, email address, or deleting an account, require appropriate re-authentication or additional verification.
Processing Sensitive Info, Transport – Verify if the payment goes through HTTP or HTTPS
Processing Sensitive Info, Field masking – Verify that the password-related fields in the web app on the Sign Up and Sign In flows are masked by default.
8. Error handling testing: break the application on purpose and read what it tells you
Errors are inevitable. What a tester checks is whether the application fails in a way that helps the user or a way that helps an attacker.
Raw server errors, stack traces, framework default pages, and database error text disclose the technology stack, file paths, library versions, and sometimes query structure. Each of those narrows an attacker’s search. The application should return a generic message to the user and record the detail in server-side logs.
Error responses also need to be consistent. Different messages for a wrong password and a non-existent account turn the login form into a user enumeration oracle, in the same way the reset request endpoint does.
Examples of testing scenarios:
Verify default error pages are not exposed – Verify that the web app displays custom error pages instead of default web server or framework error pages (for example, DO NOT DISPLAY error 500 pages with debugging information).
Debug mode disabled. Confirm the deployed environment does not run with debug or development flags enabled, and that error responses carry no environment or version headers.
9. File upload testing: upload the file the application should refuse
File upload is the highest-value target in most applications, because a successful upload of executable content is often the shortest path from user to server. Testing it with valid files confirms the feature works and nothing else.
The distinction to test is between what a file claims to be and what it is. Filename, extension, and the Content-Type header are all client-supplied and all trivially forged. Only server-side inspection of the file’s actual content establishes its type.
Where the file is written matters as much as whether it was accepted. Uploads stored inside the web root and served back from a path the application will execute turn a validation gap into remote code execution.
Examples of testing scenarios:
Upload files, Content-Type spoofing – Verify that the uploaded .pdf document will not be accepted if it appears to be a harmful file.
Verify that the server does not rely solely on the client-provided Content-Type when validating uploaded files. During testing, intercept the upload request with a proxy such as Burp Suite and modify the Content-Type value while keeping the file content unchanged. The server should validate the actual file content and reject files that do not match the expected format.
Upload files, Extension bypass – Verify that the manipulated file extension cannot bypass the validation for uploaded files; For example, rename a malicious file to an accepted extension and upload it. Confirm the server inspects the content rather than trusting the extension.
10. Security header testing: confirm the security headers are present and configured
Security headers are the lowest-effort check in this list and the most frequently missing. They are visible in the Network tab in seconds, and their absence is a finding a QA engineer can raise without any security tooling at all.
Four are worth checking on every response. Content-Security-Policy restricts which sources can execute script, which limits the impact of a cross-site scripting finding rather than preventing it. Strict-Transport-Security forces subsequent requests over TLS. X-Frame-Options or the CSP frame-ancestors directive prevents the page being framed for clickjacking. X-Content-Type-Options: nosniff stops the browser inferring a content type the server did not declare.
Presence is not the same as correctness. A CSP containing unsafe-inline or a wildcard source permits most of what it is meant to block, which was the configuration weakness we found in AI-generated code that had otherwise implemented a policy.
Examples of testing scenarios:
Headers present. Confirm Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, and X-Content-Type-Options are returned on HTML responses.
CSP is not permissive. Confirm that the policy does not include unsafe-inline, unsafe-eval, or a wildcard script-src.
Framing blocked. Load the application in an iframe on a local page. Confirm that the browser refuses to render it.
Server disclosure. Confirm that responses do not include Server, X-Powered-By, or framework version headers.
Automate what repeats, and learn what does not
With the rise of shift-left practices and AI, security testing is becoming a shared responsibility rather than a specialised task. Investing in both education and automation is what makes that shift real rather than nominal.
The split is straightforward. Checks with a stable pass condition belong in automation – headers present, HTTPS enforced, protected endpoints returning 401 without a token.
Checks that require judgement about what an attacker would want stay manual, because a script can confirm a rule holds but cannot notice that the rule is the wrong one.
Infinum invests in these skills continuously, which strengthens the QA team’s expertise and raises security awareness across the organisation.
Keep business logic in mind
Besides the technical side, the business logic of the application is also important.
From a security standpoint, the QA team should check that the application enforces its business rules on the server and that these rules cannot be bypassed by changing requests or skipping parts of the normal workflow.
A request can have valid data and still be an invalid action. For example, a user could try to use the same discount more than once, buy more items than allowed, change the price or quantity of an order by sending a modified API request, or access a later step without completing the previous one. These are cases that should be tested by modifying valid requests, repeating actions, and trying to skip steps in the workflow. The server should detect these cases and reject the request.
The application should not depend only on restrictions in the UI, because those restrictions can be bypassed by sending requests directly to the API.
Which tools to use for security testing
With so many security testing tools available, selecting the ones that fit your QA workflow matters more than trying to use them all. Five cover most of what a QA team needs, and each builds on concepts QA teams already use.
Tool | What it catches | Setup effort |
| SonarQube | Injection risks, hardcoded credentials, insecure crypto usage | Medium – CI integration |
| Postman | Missing auth, BOLA, unvalidated payloads, verbose errors | Low – already in most QA stacks |
| Burp Suite | Request tampering, parameter manipulation, fuzzing | Medium – proxy configuration |
| DevTools | Security headers, cookie flags, data in transit | None – ships with the browser |
OWASP ZAP | OWASP Top 10 classes, automated baseline scans | Low – Docker image or CLI |
SonarQube
SonarQube is a static analysis platform that inspects source code for bugs, code smells, and security vulnerabilities before anything ever runs. For QA teams, its value lies in shifting security left: QA can catch issues like SQL injection risks, hardcoded credentials, insecure cryptographic usage, and other OWASP-aligned weaknesses at the code level.
Its rulesets map to well-known standards such as the OWASP Top 10 and CWE, which gives QA a consistent basis for judging whether code meets a security baseline rather than an opinion about whether it looks safe.
One caveat with SonarQube is that a paid version is required to access the details of the reported issues.
Postman
Most people know Postman as an API development and functional testing tool, but it is also a capable ally in API security testing. QA teams can use it to probe endpoints for common weaknesses: broken authentication, missing authorisation checks, improper error handling that leaks stack traces, and endpoints that accept malformed or malicious payloads without validation.
By crafting requests that deliberately break the rules – sending unexpected data types, tampering with tokens, or accessing another user’s resources – QA can verify that the API enforces its security controls rather than assuming it does.
Postman’s scripting and automation features extend this further, which makes it well suited to building a repeatable regression suite of security checks that runs on every API change.
Burp Suite
Burp Suite’s proxy is the foundation. It lets you see and modify every request the application sends before it reaches the server, which is what makes the client-side trust checks in this article possible.
Beyond manual interception, Burp Suite offers modules including:
Intruder for automated fuzzing and payload injection
Repeater for iterating on a single request
Scanner for automated detection of known vulnerability classes (available only in the paid version of the tool).
Free alternative: Dastardly.
QA teams do not need to be full penetration testers to benefit from this tool. Learning the proxy, Repeater, and Intruder basics is enough to run meaningful security validation and to reproduce and document findings clearly for developers.
DevTools
Every modern browser ships with developer tools that require zero setup. The Network tab shows exactly what crosses the wire, which makes it the fastest way to confirm transport security, inspect request payloads before they are sent, and check response headers.
The Application tab reveals how the application handles cookies and client-side storage, making it straightforward to spot missing HttpOnly or Secure flags, or sensitive data written to localStorage.
Its real value is that it fits into work QA teams already do. Most of the checks in this article start here.
OWASP ZAP
OWASP ZAP is an open-source scanner that probes web applications and APIs for the vulnerability classes documented in the OWASP Top 10.
It runs headless and integrates into CI/CD pipelines via its API or Docker image, so baseline scans execute automatically on every build and fail the pipeline when new issues appear. Of the five tools here, it is the strongest candidate for the automated tier.
Being free and open source also lowers the barrier to adoption. QA teams can start experimenting immediately without procurement hurdles, which makes ZAP a practical entry point for organisations just beginning to formalise a security practice.
Quality and security: two sides of the same coin
A feature can work exactly as intended and still be incomplete. If it exposes user data or hands an opening, it is not finished.
Getting started requires no major investment and no bigger change to how a QA team should work. Your QA team is almost certainly running security checks already. The shift is to run them deliberately, with the second question asked after the first one passes.
QA teams are also positioned to catch what a scheduled engagement cannot. They see the application every day, across every release, in states no test plan anticipated. That is where authorisation gaps and business logic flaws surface, and neither shows up in a scanner report.
The teams that build more secure software are not necessarily the ones relying on a final security review. They are the ones where security is not seen as something that belongs only to the SecOps team
Cybersecurity is for everyone involved in building and testing software, and each team can contribute in its own way.
QA is in a good position to help and support this part. Functional and security testing often go hand in hand, and QA engineers can bring a different perspective to the table. They can spot things that might be worth raising with SecOps, learn more about the security side of the product, and help the security team see potential issues from a user’s point of view.
Additionally, AI can be another useful tool here. It can help QA teams think of security scenarios, challenge assumptions, and ask questions they might not have thought of themselves. It doesn’t replace security expertise, but it can give QA another pair of eyes when exploring potential risks.
All of this doesn’t mean that security testing becomes a QA responsibility, or that every QA engineer needs to become a security specialist.
It simply means that QA can be a good security ally, supporting the SecOps team and helping build a stronger security mindset across the team.
Because security shouldn’t be something we think about only when a security test starts. The more people who understand it and know how they can contribute, the better.
