Trusted URL and Browser Policy Violations
Trusted URL and Browser Policy Violations is a Setup page in Salesforce that logs the resource requests a user's browser blocked because of Content Security Policy (CSP) rules, plus redirects that were blocked for leaving a trusted origin.
Definition
Trusted URL and Browser Policy Violations is a Setup page in Salesforce that logs the resource requests a user's browser blocked because of Content Security Policy (CSP) rules, plus redirects that were blocked for leaving a trusted origin. Each row records one unique violation, so admins can see exactly which external script, image, iframe, font, or connection a Lightning Experience page tried to load and the browser refused.
The page is a diagnostic surface, not a setting. It tells you what broke and why, then you act on it elsewhere by adding the missing host to Trusted URLs. The list keeps only violations that occurred in the last seven days, and a daily process clears anything older.
How the page catches the silent failures CSP creates
Why CSP blocks happen in the browser, not the server
Content Security Policy is a W3C web standard. It tells the browser which sources a page may load scripts, images, fonts, styles, frames, and network connections from. Lightning Experience ships with a strict policy. By default the script-src, font-src, img-src, media-src, frame-src, style-src, and connect-src directives are all set to 'self', so resources must come from inside your org. The point is to stop cross-site scripting and code injection, and script-src even disallows 'unsafe-inline' to block inline event handlers. The catch is where enforcement happens. The browser, not Salesforce, decides to block a request. When a custom Lightning component calls a third-party API or loads a chart library from a CDN, the browser checks the policy and quietly refuses if the host is not allowlisted. Nothing appears in your Apex logs or debug logs. The user just sees a broken widget. This page exists to make those browser-side refusals visible inside Salesforce.
What a single violation row tells you
Each entry on the page describes one unique violation. The columns give you the URL the browser tried to reach, the Resource Type it was treated as, the CSP Directive that did the blocking, and the Violation Type. CSP violations raised from a Lightning Experience page carry a CSP context of Lightning, which confirms the request came from inside the Lightning runtime rather than a Visualforce page or external surface. That detail is what turns guesswork into a fix. If a row shows a connect-src violation against api.example.com, you know a component tried an XHR or fetch to that host and CSP stopped it. If it shows frame-src against a vendor's embed URL, an iframe was refused. You read the directive, identify the host, and you have the exact value to allowlist. The page does not fix anything on its own. It hands you a precise to-do list of hosts your trusted URL configuration is missing.
Blocked Redirect versus CSP Violation
The page tracks two different events under one roof, and they are not the same problem. A CSP Violation is a blocked resource load: a script, image, font, style, frame, or network call the browser refused because the host was not in your allowlist. You resolve it by adding the host to Trusted URLs against the matching directive. A Blocked Redirect is different. It fires when Salesforce stops a navigation that would send the user to an untrusted external address, which is a defense against phishing and open-redirect abuse. The fix is still to trust the destination if it is legitimate, but the cause is a redirect rather than an embedded asset. Reading the Violation Type column first saves you from chasing the wrong fix. A redirect you treat as a CSP asset block will never resolve, because the two are evaluated by separate mechanisms even though they land in the same list.
Reported entries and the seven-day window
Not every row means a user actually saw something break. Some violations are marked as Reported, meaning the resource is only blocked when stricter CSP settings are turned on. Several frame-src, font-src, and img-src requests are not enforced unless the Adopt Updated CSP Directives setting is enabled in Session Settings. A Reported row is a preview. It shows what would break once you tighten enforcement, so you can fix it before flipping the switch rather than after. The seven-day retention shapes how you should use the page. The list only holds violations from the last seven days, and a daily job deletes anything older. That keeps the view current, but it means the page is not an audit trail. If you need history, schedule daily queries against the Blocked Redirect and CSP Violations event types in Event Monitoring. Those event log files persist far longer and let you trend violations over weeks or months instead of losing them after a week.
Why developers should bookmark it during a build
The phrase "it works on my machine" carries no weight against CSP. Enforcement runs in each visitor's browser, and policy behavior can differ slightly across browser versions. A component that loads fine for the developer can fail for a user on a stricter or older browser. So the page belongs in your development loop, not just your incident response. Use it the moment you wire a custom Lightning component to anything external. Build the component, exercise every path that calls an outside host, then open Trusted URL and Browser Policy Violations to collect the URLs the browser refused. Add each one to Trusted URLs against the right directive and test again. After go-live, check it periodically too. Third-party vendors move endpoints, add new subdomains, or shift a script to a different CDN, and each change can surface a fresh violation that was never there during your original build. Catching those early keeps integrations from silently degrading in production.
Turning a violation into a resolution
Reading the page is half the work. Resolution happens on the Trusted URLs page, where you create an entry for the host and select the CSP directives it needs. The directive you choose has to match the violation. To let components reach an API or open a WebSocket, you select connect-src, often labeled for scripts and connections. For an embedded iframe you choose frame-src, for images img-src, for web fonts font-src, and so on. Picking the wrong directive leaves the resource blocked even though the host now appears trusted. Two habits make this reliable. First, allowlist only the specific hosts you actually need, since every trusted URL widens your attack surface a little. Second, document each resolution. The same vendor scripts and embed patterns tend to recur across components, so a short internal note of "this host needs connect-src plus frame-src" turns the next occurrence into a one-minute fix instead of a repeated investigation.
Resolve a blocked resource from the violations page
You do not configure this page itself. The real task is reading a violation, then resolving it by trusting the right host on the Trusted URLs page. Here is the loop an admin runs to clear a blocked resource.
- Open the violations page
In Setup, use the Quick Find box to find and select Trusted URL and Browser Policy Violations. Review the entries, remembering the list only shows unique violations from the last seven days.
- Read the row carefully
For each violation, note the URL, the Resource Type, the CSP Directive, and the Violation Type. Confirm whether it is a CSP Violation (a blocked resource) or a Blocked Redirect (a stopped navigation), because they are fixed differently.
- Create the Trusted URL
Go to Trusted URLs in Setup and click New Trusted URL. Enter a name and the exact host from the violation, including the https scheme. All external resources must use HTTPS.
- Select the matching directive
Choose the CSP directive that matches the violation, such as connect-src for an API call, frame-src for an iframe, or img-src for an image. Leave Active selected so the entry takes effect immediately.
- Test, then watch for stragglers
Reload the component and exercise the feature again. Return to the violations page to confirm the entry cleared, and check back after vendor or browser updates for new violations that appear later.
The rule that blocked the resource, such as connect-src, frame-src, img-src, font-src, media-src, or style-src. You must trust the host against the same directive that appears in the violation.
Tells you whether the event was a CSP Violation (blocked asset load) or a Blocked Redirect (blocked navigation to an untrusted origin). Read this before choosing a fix.
A value of Lightning confirms the violation came from a Lightning Experience page rather than another surface, which helps you locate the component responsible.
Controls whether a trusted URL is enforced. Deselect it to temporarily disable an entry without deleting it; reselect it to restore access.
- The list retains only the last seven days of violations and a daily job purges older ones, so treat it as a live view, not an audit log.
- Reported entries are blocked only under stricter settings; many frame-src, font-src, and img-src requests are not enforced until Adopt Updated CSP Directives is enabled in Session Settings.
- For long-term history, schedule daily queries of the Blocked Redirect and CSP Violations event types in Event Monitoring, since the page itself keeps nothing past a week.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Trusted URL and Browser Policy Violations.
- Manage Trusted URL and Browser Policy ViolationsSalesforce
- Manage Trusted URLsSalesforce
Hands-on resources to go deeper on Trusted URL and Browser Policy Violations.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Why is understanding Trusted URL and Browser Policy Violations important for Salesforce admins?
Q2. In which area of Salesforce would you typically find Trusted URL and Browser Policy Violations?
Q3. What is the primary benefit of Trusted URL and Browser Policy Violations for Salesforce administrators?
Discussion
Loading discussion…