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
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
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
Here you can review submitted feature requests and vote up the ones you like! If you can't find the feature you want - go ahead and suggest your own idea. Ideas with the highest rating can be implemented in the product.