Skip to main content

January

· 9 min read

NG Hotfix Release Update - APIsec_cloud_7.1.1.1 ( January 21, 2026 )​

Azure API Management Integration: Improved Support for Granular Azure RBAC Scopes

We resolved an issue that could prevent APIs discovered through the Azure API Management (APIM) integration from being displayed when using granular resource-scoped credentials.

What was happening

Azure Role-Based Access Control (RBAC) allows permissions to be granted at multiple hierarchy levels, including the Subscription, Resource Group, or individual resources (such as an APIM service). In this case, the integration was configured with credentials scoped directly to the APIM service resource rather than the resource group. This access model was intentionally chosen to restrict visibility to only specific resources. However, because APIsec previously relied on listing resource groups first, it could not traverse the hierarchy to locate the APIM service and enumerate APIs, even though valid access existed.

What's fixed

APIsec now supports this granular access model by:

  • Discovering resources directly at the assigned scope level
  • Parsing resource metadata to identify the associated resource groups and APIM services
  • Traversing from those services to retrieve and onboard APIs correctly

This approach enables API discovery to succeed even when credentials are narrowly scoped to specific APIM resources.

Impact for customers

  • APIs can now be discovered and onboarded when credentials are scoped at the APIM service or other granular resource levels
  • No need to broaden permissions to the resource group or subscription level
  • Better alignment with least-privilege access models commonly used in enterprise Azure environments

This enhancement ensures Azure APIM discovery works reliably across different RBAC scoping strategies while respecting customer security boundaries.

NG Production Release Update - APIsec_cloud_7.1.1.0 ( January 16, 2026 )​

This release delivers targeted improvements that help security teams discover, test, and govern APIs more accurately, automate securely at scale, and reduce noise during access validation. It introduces an API discovery workflow that guides teams to build a complete and reliable API inventory using browser traffic, source code, or automated pipelines, ensuring APIs are identified as they actually exist before testing begins.

In addition, the release includes greater RBAC testing control, deterministic credential selection for BOLA scenarios, programmatic authentication management via application scopes, team-based access via API Tokens, and support for confidential instance-level headers. Together, these updates address common enterprise challenges such as incomplete API visibility, session-sensitive endpoints, scalable integrations, and sensitive data handling, making API security testing more predictable, reliable, and aligned with real-world operational needs.

Guided API Discovery Workflow

We have introduced a guided API discovery workflow designed to help administrators, application owners, and security teams build a complete, accurate API inventory without guesswork or trial-and-error. Instead of forcing you down a single path, the platform starts by understanding your reality—how your applications are built, what access you have, and which tools you can realistically use.

What this means for you in practice:

  • No more one-size-fits-all discovery

    Whether you manage microservices, legacy systems, hybrid architectures, or something hard to describe, the workflow adapts to your environment.

  • Clear guidance, not assumptions

    The system asks practical questions about code access, browser access, CI/CD pipelines, and teams you can collaborate with, then uses those answers to recommend the most effective discovery options.

  • Multiple ways to find APIs, not just one

    Based on your situation, you are guided toward the right mix of discovery methods:

    • APIsec BOLT (Browser-Based Discovery)

      Discover APIs directly from live application traffic. By simply navigating your application in a browser, BOLT captures real API traffic, identifies endpoints and behaviors, and generates accurate OpenAPI specifications—no proxies, agents, or configuration required.

    • Code Discovery via VCS (GitHub Actions)

      Uncover APIs directly from source code within your development workflow. Code Discovery scans repositories to generate OpenAPI specifications, supports common frameworks in Java, Python, and .NET, and integrates seamlessly with GitHub pull requests to keep API visibility aligned with code changes.

    • Code Discovery CLI

      Built for automated, large-scale, or CI/CD-driven environments. The CLI enables repeatable API discovery across repositories, helping teams continuously track APIs as systems evolve and ensuring discovery scales with development.

  • Built for real-world constraints

    Even if you have only limited access, such as a browser and production credentials, the workflow helps you move forward rather than block progress.

  • Confidence you're not missing anything

    By encouraging complementary discovery methods, the experience helps uncover undocumented, shadow, or forgotten APIs that often slip through the cracks.

Why this matters

Whether you are a security team reducing blind spots, an application owner onboarding APIs quickly, or a platform team building repeatable workflows, these discovery options adapt to how you work today. You can capture APIs from live usage, extract them from code, or automate discovery in GitHub, then send everything directly into APIsec for security testing. The result is a more complete API inventory, fewer surprises, and faster, more confident security coverage.

Exclude Specific Endpoints from RBAC Testing

If you manage APIs with session-sensitive endpoints, such as logout, token revocation, or session invalidation, you can now exclude those endpoints from RBAC access checks.

Previously, RBAC testing evaluated every configured endpoint. For some APIs, this meant that logout endpoints were executed during access checks, unintentionally invalidating sessions mid-test and causing unrelated endpoints to appear inaccessible. This made RBAC maps inaccurate, misleading, and time-consuming to validate.

With this enhancement:

  • You can explicitly exclude selected endpoints from RBAC testing.
  • RBAC results reflect true authorization behavior, not side effects of session invalidation.
  • Teams spend less time debugging false negatives and more time validating real access risks.

This is especially valuable for applications with complex session management or concurrent role testing.

Deterministic Credential Selection for BOLA Create Scenarios

Testing BOLA vulnerabilities in real-world APIs often requires creating resources with the correct identity, especially in multi-tenant or role-segmented environments. This update gives you explicit control over which credential is used to create the initial resource in a BOLA create scenario.

Previously, the platform automatically selected a creator credential. In APIs where payloads, headers, or parameters include user- or tenant-specific identifiers, this could lead to inconsistent results or failed scenarios simply because the wrong credential was used.

With this update:

  • You can explicitly choose which role or credential creates the resource.
  • BOLA test execution becomes deterministic and repeatable across runs.
  • Existing scenarios that rely on dynamic or “any credential” selection continue to work as before.

The result is more reliable BOLA testing with fewer failures, clearer findings, and greater confidence that detected issues reflect real authorization risks rather than setup inconsistencies.

Manage Authentication Programmatically Using Application Scopes

If you rely on automation or CI/CD pipelines, you can now create, update, list, and test authentication credentials using API Tokens, governed by existing application-level scopes.

Authentication is essential for running meaningful security scans, yet until now, managing credentials often required manual UI interaction. This enhancement enables secure, scoped automation without introducing new or confusing permission models.

What this means for you:

  • Integrations can manage authentication credentials end-to-end.
  • Access is controlled using familiar application scopes.
  • Teams can automate authenticated scanning without compromising security boundaries.

This makes onboarding, credential rotation, and validation easier to operationalize at scale.

Team-Based Access via API Tokens

For organizations structured around teams rather than individual applications, integrations can now operate at the team level rather than per application.

  • API Tokens can now be granted read-only access to:
    • Discover teams within a business unit.
    • Retrieve applications associated with a team.
    • Correlate application data with team ownership.

This enables cleaner, more scalable integrations—especially for external platforms that aggregate or analyze security data—while preserving strict access controls.

The result is fewer integrations to manage, clearer ownership mapping, and simpler automation across large portfolios.

Confidential Instance-Level Headers

Some APIs require mandatory headers, such as API keys, for all requests, even during unauthenticated scans. You can now mark instance-level headers as confidential, ensuring sensitive values remain protected while still enabling accurate security testing.

  • With this enhancement:
    • Confidential headers are applied during scans and vulnerability detection.
    • Sensitive values are hidden from endpoint details, logs, and other users.
    • False positives caused by missing required headers are eliminated without exposing secrets.
    • Confidential header masking has also been implemented across all Dry Run workflows, ensuring sensitive values are protected during:
      • Endpoint-level Dry Runs
      • Test Credentials
      • RBAC checks
      • BOLA scenarios

This allows teams to maintain strong data confidentiality while ensuring APIs are tested realistically—a common requirement in regulated and security-sensitive environments.

Bug Fixes & Reliability Improvements:

  • OAuth2 Authentication Test URL Accuracy

    Resolved an issue where the Test Authentication results for OAuth2 displayed an incorrect authentication URL due to authentication resolution failure. The platform now consistently shows the actual endpoint used during token resolution, ensuring users can accurately validate and troubleshoot authentication flows without confusion.

  • MuleSoft Integration Stability Improvements

    Enhanced MuleSoft API onboarding to intelligently fall back from FAT-OAS to standard OAS when FAT-OAS is unavailable. This fix addresses onboarding failures experienced by some customers and ensures that APIs can be reliably discovered and registered across different MuleSoft configurations.

  • Reload Spec Endpoint Deduplication

    Corrected an issue where Reload Spec did not properly handle endpoint group duplication. Reloading specifications now behaves as expected, removing obsolete endpoints without introducing duplicates and keeping application inventories clean and consistent.

  • Hosted Agent Security Hardening

    Applied additional security improvements to the Hosted Agent to align with security best practices. These changes enhance the overall security posture without impacting existing workflows.