ReadyAPI Feature Requests

I would like the ability to mask passwords in the settings.xml file for Composite Project files. Our security team flag this as risk since usernames and passwords are exposed in this file. We would like to continue to use the Auth Repository feature while keeping our project files in Composite format. ... View more

Dear Smartbear,   we are planning to use the pre-configured Docker images (Test Runner and LoadUI Agent) to run tests in our GitLab CICD pipelines. But after consulting with our IT Security Department, only distroless images are allowed to use within our company.   The bare minimum of a distroless image - as required by our IT Security Guideline - is that it contains no package manager. It can be achieved, for example, by a multi-stage docker build, in which the package manager is removed at the last stage.   Thus, I would like to ask you to provide officially distroless Docker images for the Test Runner and LoadUI Agent.   In addition, distroless Docker images are becoming best practices and the default choice for deployment containers. So I'm pretty sure, that a lot of your users would benefit from it 🙂   Thank you very much in advance!   Best regards, your ReadyAPI user   ... View more

Hi,   The latest version of ReadyAPI 3.20.0 seems to fix encrypted properties being displayed as plain text in logs within the ReadyAPI software itself but this does not translate when running the project from Azure DevOps using the "ReadyAPI Test for Azure DevOps task" as encrypted properties are still being exposed there.   1. The project password for the task is in plain text - This property should be masked as anyone who views the task would be able to download and access the encrypted project and its properties.   2. Encrypted properties are displayed in the logs/requests as plain text The password has been encrypted in the custom properties using the "selected properties" project encryption . However, encyrpted properties are being shown in the task logs when a request that uses the properties fail or when logged using groovy script as plain text.    This display of encrypted properties as plain text is unacceptable especially when creating production tests so it would be benefical if encyrpted properties are not exposed.   Thanks, Kayleigh ... View more

Hi,   I believe there should be a feature that uses the Swagger definitions for REST API services much more profoundly. The current "Swagger Compliance Assertion" is not covering this. It's too broad and generic. I would love to have an option to automatically create the standard edge test cases based upon swagger definitions as that would save a lot of time for readyAPI customers. There is a security JSON boundary scan, but that only verifies that there is no sensitive data in the response. It doesn't doe anything with the provided swagger information. There is also no way to see what exactly the boundary scan does, except for going into the transaction log to see each individual request payload (https://support.smartbear.com/readyapi/docs/security/scans/types/boundary-json.html)   Suggestion: Button to "Create negative tests from Swagger": - Example1:  Automatically a test cases is created with a REST test step where JSON payload or request parameter is set to whatever minLength / maxLength is defined in the swagger. If for instance maxLength is 99 I want ReadyAPI to have a value set to 100 character length. Expected outcome would then be an HTTP400 (customizable with a predefined response payload check).  - Example2: Automatically test cases are created where we omit the "required" fields (be that headers, request payload parameters or query parameters). So either it's set to null or it is completely missing from the request. Again expectation would be an HTTP400 or HTTP401/403 for authorization headers.     ... View more

Hello, I'm using the latest version from RedayAPI (3.0.0) and my project is password protected - the properties are encrypted. When I want to run functional tests in pipeline, I can give the password over the command-line parameter -p but this parameter doesn't exists for the loadtestrunner.   This fact is not an error but a missing function. Without this feature, encoding the properties in a project is a major drawback when you want to automate the load test because I must deactivate the passwort protection to run the loadtestrunner. This is a strong security restriction, especially if you want to protect the passwords/token/secrets used in cloud repositories. A lot of services are provided in the cload nowadays and the trend is increasing, besides the reason I ask the reader to vote for the function to introduce the password parameter for the loadtestrunner as well.   Thanks in advance for the votes.   Greetings, Giovanni   ... View more

Generally, once you find SQL Injection or Cross Site Scripting for a parameter, you don't need to know the hundreds of other exploit strings that also worked. The important information for the developers is that parameter x has Cross Site Scripting vulnerabilities or stack trace errors. So a table with 2 columns (scan type, issue type)  that had a row for every distinct combination of scan type (e.g. SQL injection) and issue type 'sensitive data returned' or 'stack trace' would be very useful. If some requests worked and some failed the developers can always look at the report for the specific strings, but generally if you are not validating or escaping input, the specific strings that caused the issue don't matter.  ... View more