Vendor Permissions | cside docs

The Dependencies view in the cside dashboard lists every vendor and domain delivering scripts to your site. Open a vendor to see its permission grid, organized into six categories: Resource types, Sensitive APIs, Storage, Event listeners, Form field access, and Other. Each capability has an Allow and a Block control; when neither is chosen the permission is unset and the vendor keeps its default behavior.

This page explains each permission, what it covers, and what blocking it prevents.

How permissions work

Each permission has three states:

Allow (green check): the vendor’s scripts can use this capability.
Block (red shield): cside prevents the vendor’s scripts from using this capability.
Unset (default): the vendor keeps its normal behavior and cside keeps monitoring what it does. Hovering a selected control shows Clear; click it to return the permission to this state.

Permissions apply per vendor, for your whole team. When a script is not matched to a known vendor, you can set the same permissions on its domain instead.

When you block a permission, cside enforces your decision in the browser. Blocked attempts are still recorded, so you can see what a vendor tried to do after you locked it down.

Think of permissions as least privilege for third parties: each vendor only gets the capabilities it needs to do its job.

The “Used” badge

Next to a permission, a blue Used badge means cside has actually observed that vendor’s scripts exercising that capability. It’s informational only: it doesn’t change or set the Allow/Block state, and a capability can be Unset while still showing as Used. Use it alongside “Check the vendor’s recorded behavior” below to decide what’s safe to block.

Resource types

These permissions control what a vendor’s scripts can load, embed, or run on your pages.

Permission	What it covers	What blocking prevents
JavaScript	Loading and executing JavaScript, including additional code pulled in at runtime with script tags	Stops the vendor from pulling in new, unreviewed code after the page loads. This is how a compromised vendor typically escalates an attack.
Network requests	Sending and fetching data over the network with fetch and XHR	Stops the vendor from sending data out of the browser to its own servers. This is the main channel for data exfiltration.
Frames	Embedding iframes and other nested pages	Stops hidden iframe overlays, fake login prompts, and clickjacking-style UI injection.
Objects	Embedding plugin content like `<object>` and `<embed>`	Stops legacy plugin content, an old but still abused injection path.
Workers	Running web workers and service workers	Stops background scripts that run out of sight, intercept requests, or keep working after the user leaves the page.
Media	Loading audio and video	Stops unwanted audio or video loads, including media used for tracking or ad fraud.
Stylesheets	Loading external CSS stylesheets	Stops style injection that can hide page elements, overlay fake UI, or leak typed data through CSS selectors.
Prefetch	Prefetching and preloading resources	Stops speculative loading of vendor resources, which can leak browsing signals before a user interacts.
Manifests	Loading web app manifests	Stops the vendor from supplying a manifest that changes how your site installs or behaves as an app.
Images	Loading external images	Stops image loads, including tracking pixels: tiny images used to beacon data out.
Fonts	Loading external fonts	Stops font loads from the vendor, a quiet channel for tracking and fingerprinting.

Sensitive APIs

These permissions control access to device hardware and to browser APIs that turn strings into running code.

Permission	What it covers	What blocking prevents
Camera	Access to the device camera	Stops scripts from requesting camera access, so users never see a prompt they might accept by mistake.
Screen capture	Recording the screen or a window	Stops scripts from requesting screen recording, which can expose anything visible on the user’s display.
Location	Reading the visitor’s geographic location	Stops scripts from requesting your users’ physical location.
Microphone	Access to the device microphone	Stops scripts from requesting microphone access and recording audio.
Eval	Executing strings as code with `eval()`	Stops a common obfuscation technique: skimmers often hide their real payload in a string and run it with `eval()`.
Function constructor	Executing strings as code with the `Function` constructor	Stops the other main way to run a string as code, closing the loophole left when only `eval()` is blocked.
document.write	Rewriting the page with `document.write`	Stops the vendor from injecting arbitrary markup and scripts straight into the document while it loads.
Inline frames	Injecting inline frame content via `srcdoc`	Stops the vendor from creating frames whose content comes from a string instead of a URL, a way to smuggle in code that no host allowlist covers.

Storage

These permissions control access to data stored in the browser.

Permission	What it covers	What blocking prevents
Cookies	Reading and writing cookies	Stops the vendor from reading session identifiers or tokens, and from planting its own tracking cookies.
Local storage	Reading and writing persistent browser storage	Stops access to persisted data, which often includes user identifiers and cached personal information.
Session storage	Reading and writing per-tab browser storage	Stops access to per-tab session data, such as in-progress checkout state.
IndexedDB	Reading and writing IndexedDB databases	Stops access to structured browser databases, where applications often cache larger sets of user data.

Event listeners

These permissions control whether a vendor can observe how users interact with your pages.

Permission	What it covers	What blocking prevents
Clicks	Tracking where visitors click	Stops click tracking across your pages, including capture of what users tap and select.
Keystrokes	Tracking what visitors type	Stops keylogging. A script listening to keystrokes can capture everything a user types, including credentials and card numbers.

Form field access

These permissions control which form fields a vendor’s scripts can read. They are central to preventing form data theft, including Magecart-style skimming, and support PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 for payment pages.

Permission	What it covers	What blocking prevents
Email fields	Email address inputs	Stops harvesting of email addresses your users type.
File uploads	File upload inputs	Stops access to files users attach, such as ID documents or statements.
Password fields	Password inputs	Stops credential harvesting from login and signup forms.
Hidden fields	Hidden form fields	Stops reading of hidden inputs, which often hold session tokens, CSRF tokens, or internal IDs.
Address fields	Address inputs	Stops collection of home and shipping addresses.
Search fields	Search inputs	Stops capture of what users search for on your site.
Phone fields	Phone number inputs	Stops harvesting of phone numbers.
URL fields	URL inputs	Stops reading of URLs users enter into forms.
Name fields	Name inputs	Stops collection of personal names.
One-time codes	One-time login code inputs	Stops theft of one-time passcodes, which attackers use to defeat MFA.
Birthday fields	Date-of-birth inputs	Stops collection of birth dates, a key identity theft data point.
Sex/gender fields	Sex and gender inputs	Stops collection of sensitive demographic data.
Credit card fields	Credit card inputs	Stops card skimming: scripts reading card numbers as users type them at checkout.
Non-sensitive form access	Form fields that hold no sensitive data	The general form permission. Blocking stops the vendor from reading form fields not covered by a more specific permission above.

Other

Permission	What it covers	What blocking prevents
Notifications	Showing browser notifications	Stops notification prompts and push spam from the vendor.
Full screen	Switching the page into full-screen mode	Stops full-screen takeovers used to imitate browser UI in phishing overlays.
Payments	Opening the browser’s payment dialog	Stops the vendor from invoking the browser’s payment sheet or probing payment capabilities.
Browser history	Changing the visitor’s browsing history	Stops URL manipulation that can disguise the page a user is really on or trap the back button.
Clipboard	Reading and writing the clipboard	Stops scripts from reading what users copied elsewhere, such as passwords or wallet addresses, and from clipboard hijacking, such as swapping a copied payment address for an attacker’s.
Send messages	Sending cross-frame messages with `postMessage`	Stops the vendor from passing data to other frames, a common way to move skimmed data into an attacker-controlled iframe.
Receive messages	Listening for cross-frame messages	Stops the vendor from receiving instructions or data from other frames on the page.
Worker messages	Exchanging messages with web workers	Stops the vendor from moving data to and from background workers, where it is harder to observe.

Choosing what to block

You don’t need to make 40 decisions per vendor on day one. A practical approach:

Start with capabilities the vendor has no business using. Most vendors never require keystrokes, password fields, credit card fields, eval(), or the clipboard. Blocking those rarely affects functionality.
Check the vendor’s recorded behavior. The Dependencies view shows what each vendor actually does on your site. If a vendor has never used a capability, blocking it carries low risk.
Lock down the pages where the data is. On checkout and login flows, prioritize the form field permissions and Keystrokes.
Watch reports after blocking. Blocked attempts are still recorded. A vendor repeatedly attempting something you blocked is worth investigating.

If you don’t see Dependencies in your dashboard yet, it is rolling out gradually. Contact support@cside.dev to enable it for your team.

Threat Detection: how cside identifies malicious scripts automatically
Vulnerability Detection: how cside flags scripts with known vulnerabilities
PCI DSS / PCI Shield: payment page script requirements
Audit Logs: track configuration changes made by your team