Custom Platform Logos Not Rendering in Chrome Due to Local Network Access Policy – DataHub Customer Support Portal

Area: UI Issues

Sub-Area: Platform Logo Rendering / Browser Security Restrictions

Issue

When configuring custom platform logos in DataHub by setting a logoUrl in the DataPlatformInfoClass aspect, logos fail to render in Chrome while rendering correctly in Safari. This occurs when the logo image is hosted on an internal network resource (such as an internal GitHub instance or an internal image service). Chrome blocks the image request with a Local Network Access or CORS-related error. DataHub renders the logoUrl value directly as an <img> tag in the browser — it does not proxy or cache images server-side — meaning all browser-level network restrictions apply directly to the image fetch. Safari does not implement the Local Network Access specification, which is why logos render there but not in Chrome.

Error Messages

Access blocked by CORS policy: Permission was denied to access the local address space.
ERR_BLOCKED_BY_PRIVATE_NETWORK_ACCESS_CHECKS

You Might Be Asking

Why do my platform logos display in Safari but not in Chrome?
Why did platform logos suddenly stop rendering in Chrome after a browser update?
Will adding Access-Control-Allow-Private-Network headers to my image server fix this issue?
Can I host logo images on an internal server and have them render in Chrome?
What is the recommended way to set logoUrl for custom DataHub platforms?

Root Cause

Chrome version 142 and later enforce a security specification called Local Network Access (previously referred to as Private Network Access). This feature blocks requests from a less-private origin (e.g., a public or HTTPS-served DataHub instance) to a more-private resource (e.g., an image hosted on an internal corporate network host). This block occurs at the browser level, before CORS headers are evaluated, which means simply adding Access-Control-Allow-Origin or Access-Control-Allow-Private-Network response headers to the image server is not sufficient to resolve it. The behavior is distinct from standard CORS errors even though the browser may surface it under a CORS-related message.

A key diagnostic indicator: if a logo URL hosted on the same origin as your DataHub instance (e.g., https://<your-instance>/assets/platforms/mylogo.png) renders correctly in both Chrome and Safari, the root cause is confirmed as a cross-origin Local Network Access block rather than a DataHub configuration issue.

Solution

The following approaches are ordered from quickest to validate to most durable for production use.

Option 1 — Base64 Data URL (Quick Validation & Small Logos)

Encode the image as a Base64 data URL and set that as the logoUrl value. A data URL is not a network request, so it bypasses Local Network Access restrictions, CORS checks, and any authentication requirements on the image host entirely.

Convert an image to Base64 on the command line:

base64 -i mylogo.png | tr -d '\n'

Then set the logoUrl to the resulting data URL:

from datahub.metadata.schema_classes import DataPlatformInfoClass
from datahub.emitter.mcp import MetadataChangeProposalWrapper

# Encode your image file as a base64 data URL
import base64

with open("mylogo.png", "rb") as f:
    encoded = base64.b64encode(f.read()).decode("utf-8")

logo_data_url = f"data:image/png;base64,{encoded}"

platform_info = DataPlatformInfoClass(
    name="<platform-name>",
    displayName="<Platform Display Name>",
    logoUrl=logo_data_url,
    # ... other fields
)

graph.emit_mcp(MetadataChangeProposalWrapper(entityUrn=urn, aspect=platform_info))

Note: Base64-encoded data URLs can be large. This approach is best suited for small icons (PNG or SVG under ~20 KB). Verify your DataHub version accepts data URLs in the logoUrl field before relying on this in production.

Option 2 — Host Logos on the Same Origin as DataHub (Recommended for Production)
Serve logo image files as static assets from the same hostname and port as your DataHub deployment. Because the browser is already on that origin, no cross-origin or Local Network Access check is triggered.

For example, place logo files in a static assets directory served by your DataHub frontend or a reverse proxy, then reference them with an absolute same-origin URL:
```
platform_info = DataPlatformInfoClass(
    name="<platform-name>",
    displayName="<Platform Display Name>",
    logoUrl="https://<your-datahub-host>/assets/platforms/<platform-name>.png",
    # ... other fields
)
```
Option 3 — Host Logos on a Public CDN or Object Storage with CORS Enabled
Upload logo images to a publicly accessible CDN or object storage bucket (e.g., AWS S3, Google Cloud Storage, Azure Blob Storage) and configure CORS to allow the DataHub origin. Because these hosts are public (not on a private network), Chrome's Local Network Access policy does not apply.

Example S3 bucket CORS policy (allow your DataHub origin):
```
[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["GET"],
    "AllowedOrigins": ["https://<your-datahub-host>"],
    "ExposeHeaders": []
  }
]
```
Then set the logoUrl to the public CDN or bucket URL of each image.
Option 4 — Chrome Enterprise Policy (Managed Deployments Only)
If your organization manages Chrome via an enterprise policy (e.g., Google Admin Console, Jamf, or a Group Policy Object), you can pre-grant Local Network Access permission for specific DataHub origins. This allows image requests from those origins to internal hosts without re-hosting the images.

Add the DataHub origin(s) to the LocalNetworkAccessAllowedForUrls Chrome Enterprise policy:
```
{
  "LocalNetworkAccessAllowedForUrls": [
    "https://<your-datahub-host>"
  ]
}
```
This is an organization-wide configuration change and requires coordination with your IT or endpoint management team. It does not require any changes to DataHub or to image hosting.

Additional Notes

Chrome's Local Network Access enforcement began rolling out in Chrome 142 (approximately late 2025). If logos stopped rendering after a Chrome auto-update and no DataHub configuration changed, this is the most likely cause.
Safari does not implement the Local Network Access specification as of this writing, which is why logos render correctly in Safari but not Chrome. This is expected behavior and not a DataHub bug.
Image endpoints that require authentication (session cookies, API tokens, etc.) will fail to render in a plain <img> tag regardless of the Local Network Access policy, since browsers do not send credentials for cross-origin image requests by default. If your internal image service requires authentication, Options 1, 2, or 3 above are the only reliable solutions.
Adding CORS headers including Access-Control-Allow-Private-Network: true to the internal image server does not reliably resolve this issue in Chrome 142+. The Local Network Access block occurs before CORS evaluation and uses a different preflight mechanism that is not universally supported across Chrome versions.
The logoUrl field is part of the DataPlatformInfo aspect. Changes take effect as soon as the updated MCP is emitted and the DataHub UI refreshes.