This topic explains how to perform penetration testing with Parasoft SOAtest.


Penetration testing is critical to uncover security holes in your application. With Parasoft SOAtest, you can efficiently take your existing API functional testing scenarios and create security tests, adding penetration testing into your automated CI process.

Creating Penetration Testing Scenarios

SOAtest supports penetration testing of REST and SOAP APIs that are accessible over HTTP or HTTPS.

Penetration testing is supported by starting with a functional test scenario that contains the APIs that need penetration testing and then configuring those scenarios for penetration testing. Existing functional test scenarios can be leveraged and turned into penetration tests, or you can create custom simplified test scenarios meant only for penetration testing.

Repurposing functional tests for use as security tests gives the following benefits:

  1. Since functional tests have already been written, you can reuse work that has already been done, saving time and effort.
  2. To execute certain APIs, you might have to do some setup, like prepping the database or calling other APIs. If you start with functional tests that already work, this setup is already done.

The general workflow for configuring penetration test scenarios is:  

  1. Identify the test scenarios that you want to use for penetration testing and copy them. You can continue executing the original test scenarios for functional testing as normal.
  2. Add the Penetration Testing Tools to the Traffic Object output of the test clients (e.g., SOAP ClientREST ClientEDI Client, or Messaging Client) that make the API calls that need penetration testing.
  3. As the application changes, update only the functional test scenarios. Whenever you are ready to run the corresponding penetration test scenarios, repeat the above process of copying from the latest set of functional tests and then configuring the copy for penetration testing. 

Penetration testing requires a user license with the API Security Testing license feature enabled.

Best Practices for Creating Security Test Scenarios

Inherent risks of penetration testing

By its nature, penetration testing simulates malicious user activity to find security vulnerabilities in the application under test (AUT). Because of this, penetration testing may cause the following effects on the AUT or the system on which the AUT or SOAtest is running:

  • The AUT can be brought down.
  • The AUT data can be modified or corrupted.
  • If an antivirus application is installed on the machines where the AUT or SOAtest are running, it can interpret SOAtest penetration testing activity as suspicious or malicious and generate warnings or take other actions.

Following the best practices will help you mitigate these and other potential issues that may be caused by the execution of penetration tests.

  • You should maintain your functional test scenarios separately from your security test scenarios, and run them from separate test jobs. The main reason for this is that adding penetration testing to existing functional tests will likely serve to destabilize the functional tests. You need to select which functional test scenarios should be turned into automated security tests, and then make copies of the functional tests that will be maintained as separate security tests.
  • You need to be selective in which tests you choose since penetration testing is expensive; you need to maximize the attack surface of the API that is covered while minimizing the number of tests. You should consider the following:
    • The Penetration Testing Tool analyzes request/response traffic to understand which parameters in the request are available to be tested. You need to select functional tests that exercise all the parameters in each API, to ensure that every input to the API gets analyzed.
    • Within each scenario, you need to decide which API calls should be penetration tested. The same API may be referenced from multiple scenarios, and you don’t want to duplicate penetration testing on an API that is tested in a different scenario. The Penetration Testing Tool should only get added to the appropriate tests for the API(s) to be penetration tested.
    • The number of scenarios needs to be manageable so that the security test run is short enough to run at least once a day.
  • Your functional test scenarios may have set up or teardown sections for initialization or cleanup. These typically don’t need to be penetration tested.
  • If the functional test has any parameterization, you should remove it. The Penetration Testing Tool doesn't need to see multiple sets of values for the same parameters to know what to test, and sending different sets of values could just lead to making the test runs go longer due to duplicated testing.
  • You should remove all assertions from any functional test scenarios that were converted into penetration test scenarios. API functional tests will usually have assertions that validate the response from the service. When used as security tests, these assertions can fail but will be noisy when reviewing the results, since in this context you only care about the security vulnerabilities that were found.
  • Some API calls add data to the database. When using the Penetration Testing Tool against such APIs, the database can get bloated with information due to the number of attacks that the penetration testing tool directs at the API. In some cases, this can cause unexpected side effects, such as the performance of the application becoming so bad that the automated security test run cannot finish in a reasonable amount of time.  If you see behavior like this, exclude the security tests for that API from your automated run until the development team can fix the problem.
  • You need to consider whether to run your functional and security tests within the same test environment or a different one. Resetting the environment between the functional and security test runs, or using a separate environment, promotes better test stability but is usually not necessary. You can often reuse the same environment, but when you do, you should run the functional tests first and the security tests last, since the security tests can destabilize the environment for the functional tests. When you use different environments, you need to make sure that the original functional test scenarios are configured with variables so that it is easy to point the tests at different endpoints for different environments. SOAtest supports this using environment variables. (See Configuring Testing in Different Environments.)

Executing Penetration Testing Scenarios

To run your penetration testing scenarios, execute them as described in Executing Functional Tests.

  • When a REST Client or SOAP Client with an attached Penetration Testing Tool is executed, the corresponding request and response data is captured and used as a starting point by the Penetration Testing Tool to execute the penetration test.

Because penetration testing can take a long time to run, even for a single API, the Penetration Testing Tool has a built-in timeout that governs how long the tool will run before moving on to the next test. The timeout complies with the Connection Settings default timeout configured in the Misc Preferences. If the timeout is reached before the penetration testing for the current API is complete, the penetration testing for that API will be interrupted and an error will be reported. The timeout can be extended in the Misc Preferences by updating the default timeout. See Misc Settings

Reviewing Results

When running via UI, errors are reported to the Quality Tasks view, and details about the error and how to fix it can be seen by double-clicking on each error or right-clicking and choosing View Details.

More detailed results are available by generating an HTML version of the report. The HTML report will organize the errors by CWE, Risk, and Confidence.

For more information see Reviewing Results.

Suppressing False Positives

A number of rules used by the Penetration Testing Tool apply heuristics to analyze the AUT HTTP responses and raise alerts. For this reason, some of the reported errors may be false positive. Review each new error to decide whether it is an actionable item or a false positive (you may want to use the Confidence level of the alert to help your assessment).

To prevent the Penetration Testing Tool from reporting a false positive during subsequent runs, you can suppress the error in the in the Quality Tasks view or in the suppression file. See Suppressing Tasks for details.

To suppress an active scan rule for all tests, modify the default active scan policy. See Configuring Scan Policies.

Configuring Scan Policies

SOAtest's penetration testing uses active and passive scan rules to do its analysis. Active scan rules make additional (manipulated) requests to the API to attempt to discover security vulnerabilities.  In contrast, passive scan rules make no new requests to the application but instead analyze request/response data captured by the corresponding REST Client or SOAP Client to discover security vulnerabilities. SOAtest leverages OWASP ZAP for penetration testing. 

SOAtest contains two built-in penetration test profiles: one for REST APIs, and another for SOAP APIs. Each profile consists of an active scan policy and a set of passive scan rules. By default, a profile is chosen based on whether the configured test makes a request to a REST API or SOAP API.

If you want to use a custom active scan policy, you can do so by exporting a scan policy from OWASP ZAP and configuring SOAtest to use it. The exported scan policy will configure the set of active scan rules that will be used by the Penetration Testing Tool. When using a custom active scan policy, an appropriate set of passive scan rules will be automatically used based on whether the request is made to a REST API or SOAP API.

To configure SOAtest use a custom ZAP scan policy:

  1. Select Parasoft > Test Configuration to open the Test Configuration Manager.
  2. Click New to create a new Test Configuration, or select an existing one.
  3. Open the Test Configuration’s Execution > Security tab.
  4. Choose Use custom scan policy.
  5. Using the Browse button select your ZAP .policy file.

Creating Custom Active Scan Policies

You can create or modify a custom active scan policy using the SOAtest embedded ZAP located in the SOAtest ZAP installation directory:


(where version is the actual version of the com.parasoft.ptest.libs.web plugin. For example,

If you have a ZAP installation on your machine that is independent of SOAtest, you will likely have a ZAP home directory in one of the following locations:

  • Windows: C:\Users\<username>\OWASP ZAP
  • Linux: ~/.ZAP
  • Mac: ~/Library/Application Support/ZAP

Your independent ZAP installation user settings stored in these directories may come in conflict with the SOAtest embedded ZAP when you launch it. For this reason, you should launch the SOAtest embedded ZAP with a custom ZAP home directory using the -dir command-line argument. Using a command prompt navigate to the SOAtest ZAP installation directory, and launch the SOAtest embedded ZAP with a custom ZAP home directory for example:

  • Windows: zap -dir C:\Users\your_name\ZAP_SOATEST
  • Linux: ./ -dir ~/.ZAP_SOATEST
  • Mac: ./ -dir ~/Library/Application Support/ZAP_SOATEST

If you don’t have a ZAP installation on your machine that is independent of SOAtest, you can run the SOAtest embedded ZAP with either zap.bat (Windows) or (Linux, Mac) scripts located in the SOAtest ZAP installation directory.

When you launch the SOAtest embedded ZAP, it may try to use a proxy port that is already taken. If so, ZAP will prompt you to select a different port:

To create a new active scan policy or edit an existing one select Analyze -> Scan Policy Manager from the ZAP top menu. In the Scan Policy Manager dialog select an existing policy or create a new one. In the Scan Policy dialog select the active scan rules you would like to apply to your custom policy:

Your custom .policy file will be saved in the policies folder of the ZAP home directory.


If you want to add active scan rules that are not included in the SOAtest embedded ZAP installation, you can add ZAP add-ons that contain these rules to the plugin directory of the SOAtest ZAP installation directory and select those rules in a custom policy as described in this section. However, if you add or modify any ZAP add-ons in the SOAtest ZAP installation directory we can no longer guarantee proper execution of the SOAtest embedded ZAP, so proceed with caution and make necessary backups before proceeding.

Inspecting/Modifying Default Active Scan Policies

You can inspect and/or modify the default active scan policies used by SOAtest. They are located in the following folder of the SOAtest installation:


(where version is the actual version of the com.parasoft.ptest.libs.web plugin, for example,

This folder contains the following active policy files:

  • Parasoft REST.policy – used by Penetration Testing Tools attached to REST Clients.
  • Parasoft SOAP.policy – used by Penetration Testing Tools attached to SOAP Clients.

Once you’ve modified either of these policies, it will be used in the next Penetration Testing Tool invocation.

Penetration Testing Rules Supported

IDRuleCWE IDRiskTypeProfile
0Directory Browsing 548mediumActiveREST/SOAP
2Private IP Disclosure 200lowPassiveREST/SOAP
3Session ID in URL Rewrite 200mediumPassiveREST/SOAP
6Path Traversal 22highActiveREST/SOAP
7Remote File Inclusion 98highActiveREST
41Source Code Disclosure - Git 541highActiveREST/SOAP
42Source Code Disclosure - SVN 541mediumActiveREST/SOAP
43Source Code Disclosure - File Inclusion 541highActiveREST/SOAP
10003Vulnerable JS Library 829mediumPassiveREST/SOAP
10009In Page Banner Information Leak 200lowPassiveREST/SOAP
10010Cookie No HttpOnly Flag 1004lowPassiveREST/SOAP
10011Cookie Without Secure Flag 614lowPassiveREST/SOAP
10015Incomplete or No Cache-control Header Set 525lowPassiveREST
10017Cross-Domain JavaScript Source File Inclusion 829lowPassiveREST/SOAP
10019Content-Type Header Missing 345informationalPassiveREST/SOAP
10020X-Frame-Options Header 1021mediumPassiveREST/SOAP
10021X-Content-Type-Options Header Missing 693lowPassiveREST
10023Information Disclosure - Debug Error Messages 200lowPassiveREST/SOAP
10024Information Disclosure - Sensitive Information in URL 200informationalPassiveREST/SOAP
10025Information Disclosure - Sensitive Information in HTTP Referrer Header 200informationalPassiveREST/SOAP
10026HTTP Parameter Override 20mediumPassiveREST/SOAP
10027Information Disclosure - Suspicious Comments 200informationalPassiveREST/SOAP
10028Open Redirect 601highPassiveREST/SOAP
10029Cookie Poisoning 20informationalPassiveREST/SOAP
10030User Controllable Charset 20informationalPassiveREST/SOAP
10031User Controllable HTML Element Attribute (Potential XSS) 20informationalPassiveREST/SOAP
10032Viewstate 642high, medium, low, informationalPassiveREST/SOAP
10033Directory Browsing 548mediumPassiveREST/SOAP
10034Heartbleed OpenSSL Vulnerability (Indicative) 119highPassiveREST/SOAP
10035Strict-Transport-Security Header 319low, informationalPassiveREST/SOAP
10036HTTP Server Response Header 200low, informationalPassiveREST/SOAP
10037Server Leaks Information via 'X-Powered-By' HTTP Response Header Field(s) 200lowPassiveREST/SOAP
10038Content Security Policy (CSP) Header Not Set 693medium, informationalPassiveREST/SOAP
10039X-Backend-Server Header Information Leak 200lowPassiveREST/SOAP
10040Secure Pages Include Mixed Content 311medium, lowPassiveREST/SOAP
10041HTTP to HTTPS Insecure Transition in Form Post 319mediumPassiveREST/SOAP
10042HTTPS to HTTP Insecure Transition in Form Post 319mediumPassiveREST/SOAP
10043User Controllable JavaScript Event (XSS) 20infoPassiveREST/SOAP
10044Big Redirect Detected (Potential Sensitive Information Leak) 201lowPassiveREST/SOAP
10045Source Code Disclosure - /WEB-INF folder 541highActiveREST/SOAP
10047HTTPS Content Available via HTTP 311lowActiveREST/SOAP
10048Remote Code Execution - Shell Shock 78highActiveREST/SOAP
10049Content Cacheability 524informationalPassiveREST
10050Retrieved from Cache UnspecifiedinformationalPassiveREST/SOAP
10052X-ChromeLogger-Data (XCOLD) Header Information Leak 200mediumPassiveREST/SOAP
10054Cookie without SameSite Attribute 1275lowPassiveREST/SOAP
10055CSP 693medium, low, informationalPassiveREST/SOAP
10056X-Debug-Token Information Leak 200lowPassiveREST/SOAP
10057Username Hash Found 284informationalPassiveREST/SOAP
10061X-AspNet-Version Response Header 933lowPassiveREST/SOAP
10062PII Disclosure 359highPassiveREST/SOAP
10063Permissions Policy Header Not Set 16lowPassiveREST/SOAP
10070Use of SAML UnspecifiedinformationalPassiveREST/SOAP
10094Base64 Disclosure 200high, informationalPassiveREST/SOAP
10095Backup File Disclosure 530mediumActiveREST/SOAP
10096Timestamp Disclosure 200informationalPassiveREST/SOAP
10097Hash Disclosure 200high, lowPassiveREST/SOAP
10098Cross-Domain Misconfiguration 264mediumPassiveREST/SOAP
10099Source Code Disclosure 540mediumPassiveREST/SOAP
10103Image Location and Privacy Scanner 200informationalPassiveREST/SOAP
10105Weak Authentication Method 287high, mediumPassiveREST/SOAP
10106HTTP Only Site 311mediumActiveREST/SOAP
10107Httpoxy - Proxy Header Misuse 20highActiveREST/SOAP
10108Reverse Tabnabbing UnspecifiedmediumPassiveREST/SOAP
10109Modern Web Application UnspecifiedinformationalPassiveREST/SOAP
10110Dangerous JS Functions 749lowPassiveREST/SOAP
10202Absence of Anti-CSRF Tokens 352low, informationalPassiveREST/SOAP
20015Heartbleed OpenSSL Vulnerability 119highActiveREST/SOAP
20016Cross-Domain Misconfiguration 264highActiveREST/SOAP
20017Source Code Disclosure - CVE-2012-1823 20highActiveREST/SOAP
20018Remote Code Execution - CVE-2012-1823 20highActiveREST/SOAP
20019External Redirect 601highActiveREST
30001Buffer Overflow 120mediumActiveREST/SOAP
30002Format String Error 134mediumActiveREST/SOAP
30003Integer Overflow Error 190mediumActiveREST
40003CRLF Injection 113mediumActiveREST
40008Parameter Tampering 472mediumActiveREST/SOAP
40009Server Side Include 97highActiveREST
40012Cross Site Scripting (Reflected) 79highActiveREST
40013Session Fixation 384highActiveREST/SOAP
40014Cross Site Scripting (Persistent) 79highActiveREST
40015LDAP Injection 90highActiveREST/SOAP
40016Cross Site Scripting (Persistent) - Prime 79informationalActiveREST
40017Cross Site Scripting (Persistent) - Spider 79informationalActiveREST
40018SQL Injection 89highActiveREST/SOAP
40025Proxy Disclosure 200mediumActiveREST/SOAP
40028ELMAH Information Leak 215mediumActiveREST/SOAP
40029Trace.axd Information Leak 215mediumActiveREST/SOAP
40032.htaccess Information Leak 215mediumActiveREST/SOAP
40034.env Information Leak 215mediumActiveREST/SOAP
40035Hidden File Finder 538mediumActiveREST/SOAP
40038Bypassing 403 UnspecifiedmediumActiveREST/SOAP
40039Web Cache Deception UnspecifiedmediumActiveREST/SOAP
40040CORS Header 942high, medium, informationalActiveREST
90001Insecure JSF ViewState 642mediumPassiveREST/SOAP
90002Java Serialization Object 502mediumPassiveREST/SOAP
90003Sub Resource Integrity Attribute Missing 345mediumPassiveREST/SOAP
90004Insufficient Site Isolation Against Spectre Vulnerability 693lowPassiveREST/SOAP
90011Charset Mismatch 436informationalPassiveREST/SOAP
90017XSLT Injection 91mediumActiveREST/SOAP
90019Server Side Code Injection 94highActiveREST/SOAP
90020Remote OS Command Injection 78highActiveREST/SOAP
90021XPath Injection 643highActiveREST/SOAP
90022Application Error Disclosure 200mediumPassiveREST/SOAP
90023XML External Entity Attack 611highActiveREST/SOAP
90024Generic Padding Oracle 209highActiveREST/SOAP
90028Insecure HTTP Method 200mediumActiveREST/SOAP
90030WSDL File Detection UnspecifiedinformationalPassiveREST/SOAP
90033Loosely Scoped Cookie 565informationalPassiveREST/SOAP
90034Cloud Metadata Potentially Exposed UnspecifiedhighActiveREST/SOAP
110001Application Error Disclosure via WebSockets 209mediumPassiveREST/SOAP
110002Base64 Disclosure in WebSocket message UnspecifiedinformationalPassiveREST/SOAP
110003Information Disclosure - Debug Error Messages via WebSocket 200lowPassiveREST/SOAP
110004Email address found in WebSocket message 200informationalPassiveREST/SOAP
110005Personally Identifiable Information via WebSocket 359highPassiveREST/SOAP
110006Private IP Disclosure via WebSocket UnspecifiedlowPassiveREST/SOAP
110007Username Hash Found in WebSocket message 284informationalPassiveREST/SOAP
110008Information Disclosure - Suspicious Comments in XML via WebSocket 200informationalPassiveREST/SOAP
111001HTTP Verb Tampering (Parasoft proprietary rule)287mediumActiveREST

Integration with Burp Suite

SOAtest uses a preconfigured instance of OWASP ZAP under the hood to perform penetration testing. You also have the option to use the commercial tool Burp Suite for penetration testing by leveraging the extension

  • No labels