Skip to main content

February

· 15 min read

NG Production Release Update - APIsec_cloud_7.2.1.0 ( February 18, 2026 )​

Improved Reset Password Flow – Fewer Blocked Users, Faster Access​

If you've received a message like "I never got the temporary password - what do I do now?", this update is for you.

What was happening before

When a new user signed up but didn’t log in right away:

Their account remained in a "force change password" state.

  • If the temporary password email was lost or expired, they couldn't use the standard Forgot Password option.
  • The system would silently reject the request.
  • The user was effectively locked out, and the CS team had to step in manually.

This resulted in:

  • Delays in getting the platform access
  • Repeated support requests
  • Manual intervention just to unblock basic login access

What's improved

New users can now request a Reset Password link, even if they never logged in with their original temporary password.

That means:

  • If the welcome email was missed, deleted, or expired, users can recover on their own.
  • No more silent failures when using "Forgot Password."
  • No need for admins to manually recreate accounts just to unblock someone.

In practical terms:

  • Account Recovery becomes smoother.
  • Security teams avoid unnecessary access delays.
  • Application owners spend less time troubleshooting first-login issues.
  • Security posture is maintained.

Users are still required to set their own password securely. The only difference is that they are no longer blocked by their account's technical state. Password changes can be managed directly from their profile settings after login.

Why this matters

This update removes a common first-day frustration:

"I signed up, but can't get in."

Now users can regain access independently, and teams can focus on productive work instead of resolving edge cases in account state.

Continuous Endpoint Readiness Validation — Always Know the Current State, Without Manual Checks​

If you manage API security at scale, you've likely run into this situation:

  • Credentials were updated.
  • Payloads were refined.
  • Parameters were corrected.
  • A scan was executed.

And then the question arises:

"What's the current readiness state of my endpoints?"

Previously, answering that question often required manual effort.

The Challenge Teams Faced

Endpoint readiness was validated automatically only during specific setup moments, like:

  • Immediately after instance creation
  • When authentication credentials were created

While helpful, this approach created a gap in day-to-day workflows.

Readiness didn't Always Reflect the Latest Configuration.

In real environments:

  • Credentials evolve.
  • Privilege levels change.
  • Parameters and payloads are adjusted.
  • Authentication strategies are refined.

However, the readiness status reflected only the last Dry Run during setup, not necessarily the most recent working configuration.

To truly understand the latest readiness state, users often had to:

  • Manually navigate to endpoints
  • Trigger Dry Run again
  • Revalidate authentication and payloads
  • Reconfirm which credential worked

This manual loop became especially burdensome in large applications.

What's Improved

Readiness validation is now built directly into scan execution.

Every time you run a scan:

  • The platform validates endpoint reachability.
  • Authentication is verified using the active configuration.
  • Request structure and expected response behavior are checked.
  • Readiness status is automatically updated based on successful validation.

No additional manual action required.

What This Means for You

Readiness Always Reflects the Most Recent Scan

You no longer need to manually re-trigger Dry Run to understand current readiness.

If an endpoint validates successfully during a scan, its readiness status is updated automatically.

Reduced Manual Intervention at Scale

For applications with:

  • Hundreds of endpoints
  • Multiple authentication strategies
  • Iterative payload refinement

You no longer need to perform endpoint-by-endpoint validation just to understand coverage readiness.

What Remains Available

Manual Dry Run is still available for:

  • Troubleshooting specific endpoints
  • Fine-tuning parameters
  • Investigating unexpected responses

But it’s no longer required just to maintain an accurate readiness picture.

Why This Matters

Security and application teams need a dependable, up-to-date view of scan readiness, especially after making changes.

Now, readiness status is continuously aligned with real scan execution.

You can trust that what you see reflects the most recent, working configuration without extra manual effort to confirm it.

Coming Next: Preserving the Last Successful Readiness State

We are introducing an improved readiness model that preserves the Last Known Good validation state.

Instead of just two states: Ready for Deep Coverage and Ready for Testing, there will now be a third, more informative state:

Currently Not Ready for Deep Coverage

This means:

  • The endpoint was successfully validated previously.
  • It is not currently passing validation.
  • A configuration or credential change likely affected it.

Improvements to Endpoint Readiness Accuracy​

As part of continuous readiness validation improvements, we addressed two scenarios that were quietly causing confusion for users trying to determine whether an endpoint was truly testable.

These issues weren't about dry-run capability; they were about visibility and clarity.

Large Response Handling — No More Silent Readiness Gaps​

For endpoints that return very large response bodies, Dry Run results sometimes failed to update the readiness status correctly.

In practice, this meant:

● The endpoint might respond successfully.
● Authentication might work correctly.
● The HTTP status might be valid.
● But readiness wouldn't update as expected.

For teams onboarding APIs that return large payloads, such as bulk data endpoints or reporting APIs, this created unnecessary doubt:

"The endpoint works. Why isn't it marked as testable?"

What's improved​

● Large responses are now handled gracefully.
● Essential validation signals are preserved even if the response body is truncated.
● Readiness updates correctly after Dry Run.
● Users are clearly informed when a response has been truncated.

This ensures readiness reflects actual behavior, not payload size.

Correct Interpretation of Error Fields — No More False Failures​

Some APIs include an error field in the response body, even when the HTTP status is 200 OK and error = false.

Previously, the presence of the keyword "error" could be misinterpreted as a failure, even when the endpoint executed successfully.

For security and platform teams, this led to confusing outcomes:

  • Successful endpoints marked as not testable
  • Time spent rechecking configurations unnecessarily
  • Difficulty explaining readiness states to stakeholders

What's improved

  • Endpoints returning HTTP 200 with error = false are now correctly marked as testable.
  • Only genuine error responses trigger a failed readiness state.
  • Readiness logic aligns with actual API behavior—not keyword presence.

This eliminates false negatives and reduces troubleshooting overhead.

RBAC & Access Control – Consistency and Permission Integrity Improvements​

We've implemented a set of improvements focused on RBAC accuracy, permission consistency, and reducing unexpected behavior when managing access at scale.

These updates ensure that access controls reflect your current API design and user entitlements, without hidden inheritance or inconsistent enforcement.

Endpoints Re-Added After Deletion Now Require Fresh RBAC Evaluation

Previously, when an endpoint was deleted and later reintroduced (via spec reload, manual addition, or discovery), it retained its prior RBAC permissions.

While the endpoint itself was recreated correctly, its historical permission state persisted. In scenarios where:

  • Access rules had changed,
  • Teams were restructured,
  • Roles were updated,
  • Or the endpoint was redesigned,

This could lead to outdated permissions being silently reapplied.

What's Improved

When an endpoint is re-added:

It is treated as a new endpoint.

No previous RBAC permissions are inherited.

  • The endpoint enters an Inconclusive state.
  • A fresh RBAC validation or map upload is required.

This ensures that access control always reflects your current security intent, not a historical configuration.

Dry Run Stability When Switching Consolidated View

Switching the consolidated view toggle during a Dry Run execution previously triggered a new Dry Run unexpectedly.

This could create:

  • Duplicate validations
  • Unnecessary execution cycles
  • Confusion during troubleshooting

The toggle now behaves predictably without triggering unintended re-executions.

Team-Based Edit Permissions Now Fully Support Instance-Level Header Management

Previously, users granted Edit access via Teams could not manage instance-level headers even though users with direct Edit sharing could.

This created inconsistent permission behavior and limited configuration control for team-managed applications.

What's Improved

Users with Edit permissions, regardless of whether access is granted directly or via team, can now:

  • Create instance-level headers
  • Modify instance-level headers
  • Fully manage application configuration as expected

Consistent "Access Denied" Messaging for View-Only Users

Users with View-only access (via team sharing) were correctly restricted from modifying RBAC permissions, but the error message displayed was inconsistent.

Instead of a clear permission message, users saw a generic configuration failure.

What's Improved

When a user without edit privileges attempts to modify RBAC:

They now see:

"Access Denied. Insufficient permissions to perform operation. Please contact your Administrator."

This aligns RBAC messaging with other protected actions across the platform and removes ambiguity.

Gateway & Integration Stability Improvements​

We've resolved several integration behaviors that affected onboarding reliability and connection status visibility.

Azure Gateway – Credential Updates Now Restore Offline Connections

Updating credentials for an offline Azure connection previously did not restore the connection to an online state.

This created uncertainty around:

  • Whether credentials were valid
  • Whether reconfiguration was required

Connections now correctly transition to online once valid credentials are updated.

Postman Gateway – Connection Type Behavior Aligned with UI Selection

When “Make Connection Private” was not enabled, connections were still being created as private.

This mismatch between UI intent and system behavior has been corrected.

Connection type now accurately reflects the selected configuration.

AWS API Gateway – Multi-Region Auto-Onboarding Reliability Improved

Scheduled auto-onboarding using AWS Central Role ARN previously iterated through multiple accounts but did not consistently onboard APIs across multiple regions.

Multi-region onboarding reliability has been improved to ensure broader and more predictable API discovery across accounts and regions.

BOLA Scenario & Execution Improvements​

Several improvements were made to enhance clarity and reliability in BOLA (Broken Object Level Authorization) testing workflows.

BOLA Scenario Setup No Longer Stuck in Loading State

In specific cases, BOLA setup remained in a loading loop due to header behavior (e.g., missing Accept header leading to unexpected content type responses).

The platform now handles these flows more predictably and reduces dependency on manual header adjustments during setup.

BOLA Execution Logs – Accurate Status & Correct Execution Order

Previously:

  • All execution logs could appear as failed—even if only one step failed.
  • Execution logs were displayed out of configured sequence.
  • Correlation IDs and authentication context were missing.

Improvements ensure:

  • Only genuinely failed steps are marked as failed.
  • Logs appear in the configured execution order.
  • Correlation identifiers and role context are properly reflected.
  • Evidence aligns with actual execution results.

This significantly improves troubleshooting clarity during multi-step attack scenarios.

BOLA Scenario Management Now Properly Restricted for View-Only Users

Users with View-only access to an application (whether granted directly or via teams) were previously able to update or delete existing BOLA scenarios.

While View users were correctly restricted from creating new BOLA scenarios, they were not consistently restricted from modifying or deleting existing ones. This created a permission gap where users could alter security test configurations without having edit-level rights.

What's Improved

Users with View permissions can now:

  • View BOLA scenarios
  • Review configuration details
  • Test BOLA scenarios

But they cannot:

  • Update BOLA scenarios
  • Delete BOLA scenarios

This aligns BOLA scenario management with the intended RBAC model and ensures:

  • Consistent enforcement of View vs Edit permissions
  • Protection against unintended modification of security test configurations
  • Clear separation between visibility and control

Edit privileges are now required for all BOLA scenario management actions, regardless of whether access is granted directly or through a team.

Endpoint & Variable Handling Improvements​

Duplicate Variable Key Errors Resolved

Users encountered duplicate key parsing errors when:

  • Updating endpoint environment variables
  • Working with Postman collection imports
  • Modifying body parameters
  • Reloading specs with retained configuration

Variable parsing logic has been refined to prevent duplicate key conflicts and allow updates to proceed as expected.

Tenant & User Management Improvements​

"Add User" Button Available Even When Tenant Has No Users

When tenants are created without a primary contact:

  • No users existed.
  • The Tenant Administrator could not see the “Add User” option.
  • User onboarding was blocked.

The Add User option is now available even if no users currently exist in the tenant, removing onboarding deadlocks.

Dashboard Accuracy Improvements​

Homepage Instance Count Corrected

An instance count discrepancy occurred when:

  • An application without instances existed.
  • The homepage derived counts from paginated application responses.

Counting logic has been corrected to prevent inflated totals.

As part of long-term improvements, instance counts will be sourced from the Analytics service for greater performance and reliability.

Scan Behavior Improvements – Redirect Handling​

Tests Skipped When Redirected to a Different Host When a request was redirected to a different host:

  • Assertions were previously executed incorrectly..
  • Results could be misleading.
  • Request/response logs were unclear.

Now:

  • If redirected to a different host, tests are skipped.
  • Vulnerabilities are not filed in this scenario.
  • Clear messaging explains why the test was skipped.
  • If logs are available, guidance is provided for root cause validation.

If the redirect remains within the same host but changes endpoint path, assertions still run—preserving detection of proxy or gateway misrouting scenarios.

This ensures that results reflect the intended API surface.

Hosted Agent Security Update​

We resolved a high-severity vulnerability related to JDK 17.0.17 in the on-premises Hosted Agent image.

Customers deploying hosted agents will receive an updated image with security improvements applied.

UI Consistency Improvements​

Several small but noticeable UI refinements have been made:

  • Correct favicon displayed after SSO login (no longer inherits third-party branding).
  • Risk acceptance comments are preserved when updating acceptance dates.
  • Scrollbar styling is consistent across modes and resolutions, including dark mode.

These refinements ensure visual consistency and prevent accidental data loss in workflow interactions.