Salesforce FLS Comparator Expanded — Jacob Crandall

FLS Comparator lets Salesforce admins capture, compare, and apply Field-Level Security settings across fields and orgs — entirely in-browser, no external server.

PERMISSIONS

storage — persists FLS snapshots and apply-history in browser.storage.local only. Nothing is sent remotely.

tabs — identifies which tab holds an active Salesforce session to retrieve the correct instance URL.

cookies — Salesforce marks its session token ("sid") HttpOnly, so document.cookie in a content script cannot read it. The background service worker reads it via browser.cookies.get() on the Salesforce host, uses it as a Bearer token for REST/Tooling API calls back to that same org, and never stores or transmits it elsewhere.

host_permissions (.salesforce.com, .lightning.force.com, .my.salesforce.com, .sandbox.my.salesforce.com, .develop.my.salesforce.com, .salesforce-setup.com variants) — required for the background worker to make authenticated fetch() calls to the Salesforce REST and Tooling APIs. The wildcard is necessary because orgs use unpredictable customer-specific subdomains.

CONTENT SCRIPT

salesforce-bridge.content.ts runs on Salesforce domains only. It detects Set Field-Level Security pages via URL pattern and injects a launch button. It reads nothing beyond what is already in the page URL. The background worker rejects any message from a content script whose sender tab is not a recognised Salesforce hostname.

HOW TO TEST

Requires a free Salesforce Developer Edition org (developer.salesforce.com/signup).
1. Open any page in the org after logging in.
2. Open the FLS Comparator sidebar (View → Sidebar → FLS Comparator).
3. Select an object (e.g. Contact) and field (e.g. Email), then click Fetch FLS.
4. The table shows Read/Edit access for every Profile and Permission Set in the org.

No eval(), no remote scripts, no telemetry. All network traffic goes only to the user's own Salesforce org.