WCC - Compatibility and Verification for Browser Local Network Access (LNA) Restrictions

Products

• Autosys Workload Automation

Issue/Introduction

Organizations preparing for the rollout of browser-enforced Local Network Access (LNA) restrictions (scheduled for deployment in modern Chromium-based browsers such as Microsoft Edge and Google Chrome version 152) require attestation regarding the compliance and readiness of Workload Control Center (WCC).

LNA restrictions block web applications hosted on public network origins from accessing private network resources without explicit permissions to mitigate cross-site request forgery (CSRF) and local network fingerprinting risks. Users need confirmation on whether WCC 24.2 will encounter operational blocks or require specific server-side configuration changes when these restrictions are fully enforced by the enterprise browser.

Environment

Workload Control Center (WCC) 24.x

Chromium-based Browsers (Google Chrome, Microsoft Edge, Mozilla Firefox)

Resolution

Based on empirical testing under strict browser-enforced blocking conditions, WCC 24.2 is compliant with LNA enforcement and continues to function normally without requiring configuration changes to the server or URLs.

Additional Information

Validation and Testing Summary

WCC was rigorously evaluated using a Chromium-based browser environment with all localized network restriction protections explicitly forced. The following environment flags were validated:

• Local Network Access Checks: Enabled (Blocking)

• Local Network Access Checks for WebRTC: Enabled

• Local Network Access Checks for WebSockets: Enabled

• Local Network Access Checks for WebTransport: Enabled

During execution of core user interfaces and monitoring operations under these strict settings, no Local Network Access (LNA) or Private Network Access (PNA) related warnings, console errors, blocks, or failed preflight requests were observed. WCC functions as expected.

Indirect Integration Caveats & Dependencies

While core WCC application functionality handles LNA boundaries successfully, administrators must account for the following browser-to-cloud dependencies:

• WCC Contextual Help Feature: The built-in Help system integrates with external, public Broadcom cloud infrastructure (such as TechDocs, IPCE, and related online documentation resources).

• Impact of Over-Hardening: If an organization implements overly restrictive browser-level security policies alongside LNA—such as blocking outbound internet traffic or applying severe Content Security Policies (CSP) like restrictive connect-src rules—the browser may block outbound calls to Broadcom online services. This will degrade or entirely disable the context-sensitive Help utility within the WCC UI.

Implementation Recommendation:

Because exact enterprise group policy settings vary across different corporate infrastructures, it is strongly recommended to implement and validate these browser security hardening flags within a designated staging or test environment prior to a wide production rollout. This ensures that any indirect functional impacts—such as documentation access restrictions—are identified and handled within your specific network context.

Suggested Next Steps / Related Queries

• Verify that enterprise firewalls or proxy configurations permit outbound connections from client browser workstations to *.broadcom.com so that the WCC Help feature remains accessible.

• Audit your internal Content Security Policy (CSP) headers if customized via reverse proxies or load balancers directing traffic to WCC.

To speak with a customer representative or a Support Engineer see Contact Support. Scroll to the bottom of the page and click on the respective region.