Security testing has a reputation for requiring specialized knowledge that most QA engineers don’t have: CVE research, exploit development, penetration testing methodology, network-level attack tooling. That reputation is partially accurate for comprehensive security audits but mostly misleading for what QA engineers actually need to do: find the most common, high-severity vulnerabilities in the applications they test before those applications reach production. The OWASP Top 10 defines which vulnerability classes account for the overwhelming majority of real-world application breaches, and most of them can be tested with free tools and manual HTTP inspection—no penetration testing certification required.

This guide covers how QA engineers can use Burp Suite Community Edition and OWASP ZAP to intercept HTTP traffic, identify injection vulnerabilities, test authentication weaknesses, and validate access control gaps across the applications they already test. The goal is not to replace a security team but to catch the most common, preventable security bugs in the normal QA workflow, before they are found in production or during a formal security audit. For context on how security testing fits into a broader test automation strategy, see Astaqc’s manual vs. automated testing guide and test automation services page.

Why QA Engineers Should Own Basic Security Testing

Security vulnerabilities found by QA engineers during functional testing cost significantly less to fix than vulnerabilities found during dedicated security audits or disclosed by external researchers. The primary reason is that QA engineers have direct access to the application in a test environment where they can manipulate requests, test edge cases, and document reproduction steps without needing special access or a separate audit engagement. The test environment is already in use, the test data is already set up, and the QA engineer already knows the application’s functionality well enough to know which behaviors should be restricted.

The OWASP Top 10—the industry-standard list of the most critical web application security risks—is a practical starting point for QA security testing because it maps vulnerability classes to testable behaviors. SQL injection, broken access control, and security misconfiguration are not abstract threats; they are specific behaviors in HTTP requests and responses that can be observed and tested without specialist tooling. When a QA engineer intercepts a request that contains a user-controlled value that goes into a database query, they can test whether that input is sanitized by submitting SQL syntax and observing the response. When a QA engineer sees that a resource URL contains a numeric ID, they can test whether changing that ID to another user’s value returns restricted data.

The shift-left security argument applies here too: finding a SQL injection vulnerability in the QA environment takes 20 minutes; fixing it before deployment takes the same developer effort but avoids the disruption, cost, and reputational damage of a post-production disclosure. For QA teams at companies without a dedicated security function, basic security testing in the QA workflow is often the only security testing that happens before release.

Setting Up Burp Suite Community Edition for HTTP Interception

Burp Suite Community Edition is a free HTTP proxy and inspection tool from PortSwigger that captures HTTP traffic between a browser and a web application, allowing the tester to inspect, modify, and replay requests. The Community Edition lacks some automation features of the paid Professional edition but includes everything needed for manual HTTP interception, request modification, and basic vulnerability testing.

Setup requires three steps: install Burp Suite, configure the browser to route traffic through Burp’s proxy (default: 127.0.0.1:8080), and install the PortSwigger CA certificate in the browser’s trusted certificate store so Burp can intercept HTTPS traffic. The certificate installation step is what allows Burp to decrypt and re-encrypt HTTPS traffic in transit, which is necessary for testing any modern application that uses HTTPS (virtually everything in production). Once configured, every request the browser sends appears in Burp’s HTTP history tab, where it can be inspected or sent to the Repeater for modification and resending.

The Repeater is the primary tool for manual security testing in Burp. A request from the HTTP history is sent to the Repeater, where any part of the request—headers, parameters, body—can be modified and the modified request can be sent to the server to observe the response. This is how SQL injection testing works in practice: find a request with a user-controlled parameter, send it to the Repeater, modify the parameter value to include SQL syntax (a single quote is typically sufficient to detect unsanitized input), and observe whether the response changes, returns a database error, or otherwise indicates that the injection reached the query layer.

For QA engineers new to Burp, the practical workflow is: configure the proxy and certificate, browse the application normally while logged in, observe the HTTP history to understand which requests carry user data to the server, identify high-risk parameters (IDs, search fields, form inputs, authentication tokens), and then use the Repeater to test those parameters for injection, access control, and authentication weaknesses. The tool does not require any scripting or programming knowledge to use at a basic level.

OWASP ZAP as an Alternative and Complement

OWASP ZAP (Zed Attack Proxy) is a fully open-source alternative to Burp Suite maintained by the OWASP foundation. ZAP includes the same HTTP proxy and interception capabilities as Burp Community Edition and adds automated scanning that is not available in Burp’s free tier. For QA teams that want automated security scans as part of a CI/CD pipeline, ZAP is the more practical choice: it has a REST API and Docker image that allow it to run as part of a build pipeline without a GUI, and its active scan identifies a range of vulnerabilities automatically.

ZAP’s passive scan mode runs in the background while the tester browses the application, flagging potential vulnerabilities (missing security headers, cookies without secure flags, information disclosure in error messages) without sending any attack traffic. The active scan sends actual attack payloads to test for vulnerabilities, and should be run only against test environments where sending attack traffic is permitted. The active scan is not a replacement for manual testing—it generates false positives and misses context-dependent vulnerabilities—but it covers a breadth of common issues quickly and is suitable as a baseline check in CI.

Testing the OWASP Top 10 with HTTP Interception

The OWASP Top 10 2021 edition defines these vulnerability classes in order of risk: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures, software and data integrity failures, security logging and monitoring failures, and server-side request forgery. Not all of these are testable through HTTP interception, but the first three—broken access control, injection, and cryptographic failures—are the most common and the most directly testable by QA engineers.

Broken access control is tested by checking whether resources that should be restricted to specific users or roles are accessible when accessed directly. In practice: log in as User A, capture a request to a resource that belongs to User A (an order, a profile, a document), log out, log in as User B, and replay the original request in Burp Repeater with User B’s session. If the response returns User A’s data, the access control is broken. This is also called an Insecure Direct Object Reference (IDOR) test. It requires no special tools beyond an HTTP proxy and two test accounts.

Injection (SQL injection, command injection, LDAP injection) is tested by submitting characters that have special meaning in the target query language and observing the response. For SQL injection, a single quote appended to a parameter value is the minimum viable test: if the application returns a database error or behaves differently from the baseline response, the parameter is potentially injectable. More thorough SQL injection testing uses payloads from resources like the PayloadsAllTheThings repository, but the single-quote test identifies the most obvious cases quickly.

Cryptographic failures are tested by inspecting whether sensitive data is transmitted over HTTP instead of HTTPS, whether session tokens appear in URLs (where they end up in server logs), and whether cookies carry the Secure and HttpOnly flags. These checks are purely observational in Burp’s HTTP history and do not require active attack payloads.

Integrating Security Testing Into the QA Workflow

Security testing becomes sustainable when it is attached to existing QA activities rather than treated as a separate, periodic audit. The most effective integration points are: HTTP proxy setup during normal exploratory testing sessions, a security checklist attached to the test cases for each new feature, and automated ZAP scans in the CI pipeline as a baseline gate.

For feature-level security testing, the practical approach is to keep Burp or ZAP’s proxy running during normal exploratory testing. The HTTP history accumulates automatically, and at the end of an exploratory session the tester can review which requests carried user-controlled parameters and spend 10–15 minutes on targeted checks: replay a resource request from another account, append a single quote to an ID parameter, check whether the response headers include expected security headers. This adds minimal time to an exploratory session but catches the most common issues without requiring a dedicated security testing sprint.

For CI integration, ZAP’s Docker image supports a baseline scan (passive checks only, no attack traffic) that runs against a staging environment in roughly two to five minutes. The baseline scan flags missing security headers, insecure cookies, and exposed server information without requiring a running user session. For a more thorough CI check, the full active scan requires a test environment with known test credentials, an authentication script, and a scope configured to avoid scanning external services. The ZAP documentation covers this setup; for teams using GitHub Actions or GitLab CI, the OWASP ZAP GitHub Action simplifies the pipeline integration to a few lines of workflow configuration.

For teams that want to go further than manual testing but cannot justify a dedicated security engineer, Astaqc’s test automation services include security testing coverage as part of embedded QA. See the hire-a-team page for how embedded coverage works. The outsourcing QA guide covers when to bring in external coverage versus building internal capacity. For context on TestInspector’s role in security-adjacent testing—specifically for validating authentication flows including OAuth 2.0 and SAML SSO—see the TestInspector product page.

Frequently Asked Questions

Do QA engineers need a security certification to do basic security testing?

No. Basic security testing using HTTP interception tools like Burp Suite or OWASP ZAP does not require a security certification. The OWASP Top 10 and the accompanying OWASP Testing Guide provide a structured methodology that QA engineers can follow without a penetration testing background. Certifications like OSCP, CEH, or GWAPT are valuable for roles that require advanced offensive security techniques, but they are not prerequisites for adding security checks to a functional QA workflow. The most important knowledge is familiarity with the application under test and an understanding of how HTTP requests and responses work, both of which QA engineers already have.

Is Burp Suite Community Edition sufficient or do teams need the Professional edition?

Burp Suite Community Edition is sufficient for manual HTTP interception, request modification, and the most common security tests: injection testing, access control validation, and authentication flow inspection. The Professional edition adds an automated scanner, the Burp Collaborator for out-of-band vulnerability testing (blind SSRF, blind SQL injection), and faster Intruder rates. For QA teams doing manual security testing as a supplement to their functional workflow, Community Edition covers the majority of use cases. For dedicated security testing that requires automation or out-of-band detection, the Professional edition becomes necessary.

How should QA engineers handle security vulnerabilities they find?

Security vulnerabilities found during QA should be reported through the same defect-tracking workflow as functional bugs, with a severity classification that reflects the potential impact. Injection vulnerabilities, broken access control issues, and authentication weaknesses should be classified as high severity and flagged immediately to the development team, rather than queued in a normal sprint backlog. Teams with a dedicated security function should route confirmed security findings through the security team’s disclosure process. For teams without a dedicated security function, a written report with reproduction steps, the intercepted request and response, and an impact assessment is typically sufficient for the development team to investigate and prioritize a fix.

Can security testing be automated in a CI/CD pipeline without disrupting normal deployments?

Yes. OWASP ZAP’s baseline scan (passive checks only) can run in CI without attack traffic, making it safe for any environment. The baseline scan does not send injection payloads or probe for vulnerabilities that require authentication; it checks response headers, cookie configurations, and information disclosure in error messages. For active scanning in CI (which does send attack payloads), the scan should run only against a dedicated test environment with explicit permission, not staging environments that are also used for manual testing or demos. ZAP’s GitHub Action and Docker image make pipeline integration straightforward, and most CI platforms support it without additional infrastructure.

What is the difference between security testing and penetration testing, and which applies to QA?

Penetration testing is a formal engagement in which a security professional attempts to compromise a system by exploiting vulnerabilities, often with the goal of demonstrating the full impact of a successful attack. It requires specific authorization, a defined scope, and specialized skills. Security testing in the QA context is narrower: it is the practice of checking that the application does not exhibit common vulnerability patterns before release, using the same test environment and test data that QA engineers already have access to. QA-level security testing covers the detection phase—does this parameter appear to be injectable, is this resource accessible without proper authorization—rather than the exploitation and impact-demonstration phase that penetration testing involves. The two are complementary: QA security testing catches the most common issues early, and periodic penetration testing provides deeper assurance for the issues that require specialist expertise to find.

Should security testing use production data or test data?

Security testing should always use test data in a test environment, never production data. Sending attack payloads (SQL injection strings, XSS payloads, IDOR probes) to a production environment can trigger alerts, corrupt data, or be logged in ways that implicate the tester rather than the attacker. The test environment should be as close to production as possible in configuration—same security headers, same authentication mechanisms, same database schema—so that findings in the test environment are representative of production behavior. Production credentials or PII in the test environment should be replaced with synthetic test data before security testing begins.