Automation Analytics & Intelligence (AAI) Requirements and Preparation for Browser Local Network Access (LNA) Restrictions

Products

• Automation Analytics & Intelligence

Issue/Introduction

Organizations deploying browser-level Local Network Access (LNA) restrictions (such as those enforced in Google Chrome and Microsoft Edge) require verification that AAI is prepared for these security changes.

Modern browsers enforce LNA restrictions to prevent web applications hosted on public network origins from interacting with private network resources without explicit permissions. This is designed to reduce the risk of cross-site request forgery (CSRF) and local network fingerprinting. Application and browser owners need to know if any server-side configuration updates are necessary for AAI to remain fully operational when these browser restrictions are active.

Environment

Automation Analytics & Intelligence (AAI) / JAWS 24.1.x

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

Resolution

No server configuration changes are required for the AAI Web UI or API under a standard, default same-origin deployment (where both the Web UI and the API backend are served from the identical host/origin).

Additional Information

Empirical Verification Methodology

To confirm that your AAI 24.1.x deployment complies with browser LNA requirements, perform the following validation:

1. Launch a deployed instance of the AAI Web UI using Google Chrome.

2. In the address bar, navigate to: chrome://flags/#local-network-access-check

3. Locate the setting and change it to Enabled (Blocking).

4. Thoroughly test and exercise all primary application flows within the Web UI:

   • Dashboard

   • Job Streams

   • Jobs

   • Machines

   • System Monitor

   • Data Insights

   • AI Insights

   • Admin

5. Open the browser's Developer Tools (F12), switch to the Network tab, and verify that no requests are blocked and no LNA permission prompts disrupt the workflow.

Exceptions & Mitigations for Non-Standard Deployments

If your specific deployment architecure serves the AAI Web UI from a public origin (e.g., via a CDN or external-facing reverse proxy) while the API backend resides entirely on a separate, standalone private network host, the browser will classify the connection as crossing a public-to-private boundary. This scenario will trigger LNA warning prompts or connection blocks.

If you utilize this type of segmented architecture, apply one of the following mitigations:

• Recommended approach: Reconfigure your delivery chain (reverse proxy or API gateway) to present both the Web UI and the API under a single, unified domain/origin (same-origin policy).

• Managed Environment Policy: In managed corporate environments, administrators can configure a Chrome Enterprise Policy to explicitly allow the connection. Pre-grant LNA permissions for the specific application origin using the LocalNetworkAccessAllowedForUrls policy rule to bypass user-facing prompts.

Suggested Next Steps / Related Queries

• Review network topology and routing architecture to ensure the AAI Web UI and API communicate over a unified origin boundary.

• Coordinate with internal browser management teams to push the LocalNetworkAccessAllowedForUrls policy if a multi-origin setup is required by corporate infrastructure rules.

 

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.