Mask Password in settings.xml file for Composite Projects
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.
Masking encrypted properties in ReadyAPI Test for Azure DevOps task instead of plain text
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
Distroless docker images for Test Runner and LoadUI Agent
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 imagesare 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 userAutomatically create testcases/assertions based on swagger definitions
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.
Add password parameter for the loadtestrunner
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
Ability to access InSite Admin console via HTTPS
There should be a way to configureInSite boxes to use HTTPS rather than cleartext HTTP for the admin interface. As it is now, accessing these devices is done in an unsecure method which could be compromised. According to support, the 1.6.3 version of the software that is running on these boxes does not have this ability and although it is thought to be included ina future release, there is no predetermined date for release. This is just one of the features that these InSite boxes fail to provide for customers. As such, I believe that a more robust effort should be made to make the InSite boxes comparative in nature to running scripts through thepay per click methodology.Secure reports should have a table of scan type and types of error found for each scan
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 escapinginput,the specific strings that caused the issue don't matter.Looking for Ready!API Users
If you are a Ready!API user feel free to contact me directly. I'm looking to observe how you are using the product. I would like to capture your emotions and interactions when using the application as I'm working on improving the usability of the application. You can email me directly at veronica.clarke@smartbear.com. - Veronica {Lead Uxer}
