Product Updates

We are excited to announce the general availability of Broken Object Level Authorization (BOLA) detection for OpenAPI targets, starting today. This feature uses artificial intelligence (AI), particularly large language models (LLMs), to identify unauthorized data access risks. You can now test for these vulnerabilities using the built-in API Normal or API Full scanning profiles.

BOLA is ranked as the primary risk in the OWASP API Top 10. By automating the detection of this complex vulnerability, we help you move beyond manual security reviews and reduce the risk of data leaks. Our goal is to provide proactive protection for your APIs by identifying authorization flaws before they can be exploited.

To use this feature, you must configure API target authentication for two separate users. The second user acts as the attacker and should have the same or lower privileges than the first user, and should not have access to the first user's resources. Once configured, our scanning engines will automatically attempt to detect if the second user can inadvertently access data belonging to the first, providing clear visibility into potential authorization gaps.

To learn more, visit How to set up your target for testing BOLA vulnerabilities? in our user documentation.

We're excited to introduce the first automatic solution for correlating static application security testing (SAST) and dynamic application security testing (DAST) findings. By connecting Snyk Code issues with Snyk API & Web results, we can now pinpoint the exact line of code responsible for a DAST vulnerability, helping you understand exactly where your code needs to be fixed and speed up your remediation process.

Vulnerabilities discovered during DAST can often be difficult and time-consuming for developers to locate within the source code. This update automates that manual search process. By using artificial intelligence to map runtime findings back to static code analysis, we're helping your teams reduce the mean time to remediate and focus on fixing issues rather than finding them.

In order to use our SAST/DAST correlation, you just need to link your Snyk API & Web targets to your Snyk Code projects and scan your API & Web targets the way you're used to. We'll do all the heavy lifting for you, and show you the corresponding SAST issue that matches our DAST finding, with the context and link directly to the code that needs to be fixed to mitigate the vulnerability.

Learn more about it here

We’ve introduced the follow-scan command to the Snyk API & Web (DAST) command-line interface (CLI) starting with version 0.0.1a15. This update allows the CLI to wait for a scan to finish before your CI/CD pipeline continues. We've also added new configuration options that let you set time limits for scans and define specific vulnerability thresholds that will automatically fail a build. After each run, we provide a direct link to your results for faster triaging.

You can now automatically block high-risk code from progressing through your CI/CD pipeline. By using the latest CLI version, you gain native control over build failures without needing to manage complex workarounds or manual checks.

To learn more, visit Snyk API & Web CLI documentation.

We’ve activated direct links to Snyk Learn lessons within the findings details pages of Snyk API & Web. When you are reviewing a vulnerability, you can now find educational content under the Description tab. Snyk Learn provides hands-on lessons to help you understand, prevent, and fix security issues in your code.

We want to bridge the gap between identifying a security risk and knowing how to remediate it. By embedding these lessons directly where you work, we're making it easier for you to build security knowledge without leaving the platform.

You can now quickly access expert-guided security training for specific vulnerabilities you encounter. This helps you not only resolve the current issue but also acquire the skills to prevent similar vulnerabilities in the future, ultimately enhancing your overall security posture.

To learn more, visit Snyk Learn.

We added support for mutual TLS (mTLS) configuration for Web, OpenAPI, and Postman targets in Snyk API & Web. This allows you to extend your security testing to cover even your most strictly secured and authenticated endpoints.

We implemented this feature to support organizations that required higher levels of security or mutual trust between client and server. This allows our crawler and scanner to authenticate successfully with services that enforce strict mTLS requirements, ensuring comprehensive security coverage for your protected targets.

In the authentication tab for your Web and API targets, you will see a new CLIENT AUTHENTICATION CERTIFICATE module under your target Settings. You can use this to upload the necessary certificates for authentication. This change allows you to scan targets that were previously inaccessible due to mutual TLS requirements.

To enable this feature, please contact the Sales team.

To learn more, visit How To Configure Mutual TLS Authentication in our user documentation.

Experience greater flexibility in authenticating your scans with the new Signature capabilities for API targets. With Snyk API & Web, you can now configure signed requests using your own algorithms.

We added this feature to support complex authentication requirements that require signed requests. By providing a dedicated space to manage these signatures, we're making it easier for you to run automated security scans against protected API endpoints that verify message integrity and authenticity.

If you have the message signature feature enabled, you can now navigate to your API target settings to set up signing methods. This ensures your scans can successfully authenticate with APIs that require cryptographic signatures for every request.

To enable this feature, please contact the Sales team.

To learn more, visit How to configure Signed Requests for API Targets in our user documentation.

We are introducing a more robust and customizable risk acceptance workflow. While providing a Reason for acceptance remains a mandatory requirement for all users, account owners can now also mandate the following fields:

• Expiration Date: The date when the risk acceptance expires.

• Approver Name: The individual who authorized the risk acceptance.

• Approval Date: The date of the approval.

Once an acceptance period expires, the finding's status will automatically revert from Accepted Risk to Not Fixed, ensuring it is reviewed again. All acceptance details are captured in the finding's log to provide a complete audit trail.

We understand that manually tracking accepted risks is inefficient and can lead to overlooked vulnerabilities. This update automates the lifecycle of accepted risks, creating a clear, auditable, and enforceable process that ensures expired risks are never forgotten.

• For account owners: A new configuration module is available in Settings > Scan Settings where you can define the new mandatory fields for your risk acceptance process.

• For all users: The Accept Risk modal will continue to require a Reason and will now also display any additional fields required by the account owner. Any risk accepted with an expiration date will automatically re-enter the workflow as Not Fixed upon expiration, prompting a timely review.

To learn more, visit Configure the risk acceptance workflow in our user documentation.

We're giving you more control over how scans behave when a navigation sequence fails. In your Target Settings, you'll now find an option to immediately fail a scan if a navigation sequence cannot be completed. When enabled, the scan stops right away, allowing you to fix the issue sooner.

Previously, a failed navigation sequence would not stop a scan, potentially leading to incomplete results and wasted resources. This change allows you to get faster feedback on broken test sequences, saving time and preventing tedious manual reviews to identify why a scan may not have covered the intended user journeys.

Starting September 30, 2025, you will see a new checkbox in the Navigation Sequences module within your Target Settings: When a navigation sequence fails, fail the scan immediately and notify me. This option is disabled by default, so existing scans will continue to run as they do now. To enable this fail-fast behavior, you will need to edit your Target Settings. You can also configure new notifications for these failures in your Slack integration settings.

To learn more, visit How to set up Navigation Sequences and Slack integration in our user documentation.

We are enhancing how secrets and sensitive data are managed in Snyk API & Web. Effective today, you can designate specific fields as sensitive within your target settings, ensuring their values are automatically masked. Furthermore, Account Owners now have a new level of control with the ability to make sensitive information permanently non-retrievable after it is saved.

This enhancement is designed to significantly reduce the risk of accidental information disclosure and prevent unauthorized access to your sensitive data. By giving you granular control to define and mask specific fields, we are moving beyond a reliance on simplistic patterns and heuristics. The option to make secrets non-retrievable adds a critical layer of security, ensuring that once a secret is stored, it cannot be exposed again through the application.

This update introduces two key changes:

• For Account Owners: A new module is available on the Settings > Authentication page. This allows Account Owners to enforce that all designated sensitive information becomes non-retrievable for everyone in the account once saved.

• For all users: When configuring a target, you will now see a 'Mark as sensitive' checkbox for relevant fields. Selecting this option will automatically mask the field's value after it is saved. This applies to configurations such as:

  • API authentication payload

  • Login form

  • Login sequence

  • Basic authentication credentials

  • Custom headers and authentication headers

  • Custom cookies and authentication cookies

  • API Parameter Custom Values

  • Postman Environment Values

To learn more, visit How to manage secrets and sensitive data in Snyk API & Web in our user documentation.

Get ready to supercharge your security prioritization! Snyk API & Web is rolling out a new Critical severity level for findings. This enhancement brings our platform even closer to industry standards, helping you zero in on the most urgent vulnerabilities that demand immediate attention.

Key Dates

• September 2, 2025: The Critical severity level will become visible within the Snyk API & Web UI. While no findings will be assigned this severity yet, this is your prime opportunity to prepare your systems. Read this article for more information.

• September 16, 2025: Snyk API & Web will begin automatically assigning the Critical severity to all eligible findings (those with a CVSS score of 9.0 or higher). Existing finding severities won't change unless they are detected in a new scan after September 16th.

This update empowers you to focus on what matters most in safeguarding your applications. If you have any questions, please reach out to Snyk’s support team.