Guide
Configure JavaScript permissions
Apply least-privilege browser capability controls using observed behavior, documented purpose, testing, and reviewed exceptions.
Last reviewed September 12, 2026
JavaScript permissions in SiteWall control supported browser capabilities at global, provider, or resource scope. Compare observed use with the script’s documented business purpose, choose the narrowest reviewed permission set, and test representative journeys before enforcement. Automatically derived permissions reflect captured behavior and may not include conditional or infrequent activity.
Browser capability presets
Strict enables the minimum execution and content read/query set. Balanced adds common event, network, storage, and canvas access. Permissive enables every listed capability. Custom appears when the individual selection no longer matches a preset. Treat a preset as a starting point and validate real journeys.
Configure granular browser capabilities
Browser capability policies define which supported browser behaviors are available to client-side resources. Configure them only after SiteWall has observed representative journeys and the resource owner has confirmed what the website needs.
Choose the correct policy layer
Use the following table to understand how each area supports the task.
| Layer | Use it when | Effect |
|---|---|---|
| Global | The rule should be the default for the project. | Applies broadly unless a more specific policy overrides it. |
| Provider | All relevant resources associated with one provider need the same decision. | Overrides the global value for that provider. |
| Resource | One individual resource needs a different rule. | Creates the narrowest supported override. |
Review what the resource uses
- 1.
Open the relevant inventory record
Open Inventory, find the resource you plan to control, and review its observed API access, destinations, affected pages, and provider.
- 2.
Confirm the business function
Ask the website or service owner what the resource is expected to do. Compare that purpose with the capabilities SiteWall observed during representative journeys.
- 3.
Decide the narrowest appropriate scope
Use a resource policy for an exception affecting one file, a provider policy for a consistent service-wide decision, or the global policy only for a reviewed project default.
Configure the capability policy
- 1.
Open Policies
Select Policies in the left navigation, then choose Global, Providers, or Resources according to the scope you selected.
- 2.
Open the target policy
For a provider or resource policy, find the target and open its edit control. Confirm the displayed name and current inherited or overridden state before changing anything.
- 3.
Review the current profile
In Browser Capabilities, inspect the active preset and individual capability toggles. Inherit uses the broader policy; a custom value creates an override at the current layer.
- 4.
Use observed permissions as a starting point
When the product offers permissions derived from observed use, review the proposal against representative traffic and the owner’s expected function. Derived permissions reduce manual work, but untested behavior may still be missing.
- 5.
Apply the minimum reviewed change
Select the intended preset or adjust only the necessary capability groups. Avoid changing unrelated permissions in the same review.
- 6.
Save and verify the effective state
Save the policy, reopen the target, and confirm that the displayed effective value matches your decision at the correct global, provider, or resource layer.
Common capability groups
Use the following table to understand how each area supports the task.
| Group | Examples of affected behavior | What to validate |
|---|---|---|
| Storage Access | Cookies, local storage, and session storage. | Authentication, consent, preferences, and session continuity. |
| Network Access | Requests made through fetch, XHR, or related interfaces. | Required endpoints, submissions, analytics, and external services. |
| Script Execution | The resource’s JavaScript execution environment. | The feature itself and dependent scripts. |
| DOM Modification and Content Reading | Reading or changing page content and elements. | Forms, widgets, accessibility, personalization, and page layout. |
| Device and User Features | Location, camera, microphone, profile, clipboard, or notifications. | Only the user journeys designed to use those features. |
| Advanced APIs | Canvas, WebAssembly, event listeners, DOM queries, and other supported access. | Rendering, fraud controls, editors, media, and interaction handling. |
Validate the change
- 1.
Run the affected journey
Repeat the pages and actions identified before the change. Include consent choices, authentication state, regional behavior, and conditional features when relevant.
- 2.
Check the website and SiteWall
Confirm that required functionality, browser requests, performance, and user-visible behavior remain healthy. Then inspect new SiteWall observations for the same journey.
- 3.
Record the decision
Document the target, layer, previous and new values, business reason, approver, validation result, known coverage gaps, and recovery action.
Common questions
Should I begin with the strictest preset?
Not automatically. Begin with observed use and the resource’s confirmed purpose, then choose the minimum access that supports representative journeys.
Why is my change not taking effect?
Confirm that you edited the correct project and target, saved the change, and understand whether a more specific provider or resource override determines the effective value.
Are derived permissions guaranteed to be complete?
No. They reflect supported capabilities observed in available traffic. Test conditional and infrequent journeys before relying on them operationally.
Derive permissions from observed use
Use observed capability and destination records to propose the smallest policy that still supports the resource’s expected function. Review more than one representative session, select only the required capabilities, save at the appropriate policy layer, and rerun the user journeys that depend on the resource. SiteWall provides the observations; an operator approves the policy.