Security testing checks whether a system protects data and actions against misuse. For QA, it extends the familiar question of whether a feature works correctly: can someone obtain another user's file, repeat an unauthorized action, store dangerous input, or bypass a restriction with a direct request?
Basic security testing need not begin with a collection of attack strings. Understanding assets, users, trust boundaries, and failure consequences is more useful. It connects tests to actual product risks and produces reproducible evidence.
Define scope and conditions
Use an agreed environment, test accounts, and prepared data. Record available roles, endpoints, integrations, permitted checks, and environment limitations. Tests that generate heavy traffic or affect availability need a separately agreed profile; they differ from ordinary permission checks.
Describe allowed and prohibited operations as the basis for expected results. A manager may legitimately see every order belonging to their team. Without ownership rules, QA can report a false vulnerability.
Start with assets and trust boundaries
List what the product must protect: personal data, money, documents, tokens, administrative actions, and availability. Map data through the browser, API, queue, storage, and external services. Incorrect trust assumptions often arise at component boundaries.
A hidden client field should not let the client decide an authorized price or object owner. Values from imports or partner services are not automatically safe either. QA checks rule enforcement at each significant boundary.
Separate authentication from authorization
Authentication establishes identity; authorization permits a particular action. Check session validity and expiration, logout, permission revocation, role access, and object ownership. A successful login does not permit reading every document.
Build a role × object × action matrix. For every important allowed operation, test denial for another user's object and an insufficient role. Exercise both the UI and direct API requests in the test environment. Hiding a button without a server-side check does not protect a resource.
Check the entire data path
Data can leak through API responses, downloads, URLs, push notifications, caches, and diagnostic logs. Check beyond the main screen. After switching accounts, the previous user's private documents must be inaccessible wherever the product promises data separation.
For input, assess server validation and safe handling at the point of use. SQL parameters must remain data, and user text must render in the appropriate context without execution. Size, file-type, and action-frequency limits must be enforced at the correct layer, beyond the client form.
Using standards and tools
OWASP ASVS helps select testable security-control requirements. WSTG describes web testing approaches. Top 10 maps common risk classes but does not provide complete coverage for a particular application.
SAST examines code, DAST examines running application behavior, and SCA examines dependencies and associated risks. These complement each other. A scanner can miss a business access-control flaw, and a vulnerable library finding requires relevance checks. A tool result starts an investigation rather than automatically deciding a release's fate.
Practical example: downloading a report
Prepare accounts A and B in different test organizations and an administrator with a defined permission scope. Create a report in organization A and retain its ID and download link. Check the full generation, status, and download chain.
- →A creates a report and receives a file containing only A's data.
- →B uses A's report ID: the API reveals neither status nor contents if policy prohibits access.
- →B opens the direct link: behavior follows the file-protection model, and knowing its ID does not bypass checks.
- →After deletion or expiry, the link no longer grants access according to requirements.
- →The administrator receives only the capabilities allowed by their role and organization scope.
For temporary signed links, explicitly test the intended model: who can use them, how long they last, and when they are revoked. Instant revocation cannot be assumed if the architecture does not promise it; discuss that residual risk as a requirement.
Errors and security-component failures
Protection must remain meaningful during exceptional conditions. Within the agreed test, introduce controlled authorization-service failure, unavailable key storage, or malformed tokens. A failed check must not become permission to act.
Compare responses with actual state. An API might return access denied after already queuing work. Following denial, verify that no report was created, email sent, or record changed. Check side effects as well as HTTP status.
Reporting findings and retesting
Record the role, object ownership, preconditions, exact sanitized request, actual result, and expected policy. Provide minimal evidence using test data: one improperly accessible object is sufficient. Assess consequences with a specialist in light of the user's actual capabilities.
After a fix, check the original scenario, neighboring operations, other roles, and background processing. Protecting one button may leave the same flaw in a mobile API or download. Add the confirmed check to regression at the layer enforcing the control.
Key takeaways for QA
Effective security testing starts with a clear prohibition and ends by verifying data and side effects. Consider roles, ownership, session lifecycle, input handling, and security-component errors. Deep threat investigation requires specialist expertise, while everyday QA can already address significant risks through systematic checks.