# Page Protection

_Monitor third-party scripts and security headers to detect unauthorized changes and meet PCI DSS v4 requirements._

Page Protection works by intercepting requests to all third-party scripts on your page (including Evervault's). We monitor the source code for every script load and trigger an alert if any changes are detected. We also monitor for new scripts being added to a page as well as changes to security headers.

Evervault Page Protection helps protect companies from sophisticated card data breaches, while directly addressing new requirements in PCI DSS Version 4:

- [Prevent Unauthorized Scripts (6.4.3)](https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf#page=157)
- [Verify Script Integrity (6.4.3)](https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf#page=157)
- [Maintain a Script Inventory (6.4.3)](https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf#page=157)
- [Header Tamper and Change Detection (11.6.1)](https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf#page=292)

With monitoring and alerting, you'll detect potentially malicious JavaScript changes before they impact your customers — without the noise.

## Getting started

To get started with page protection, you need to register the page you want to monitor. Inside of the Evervault Dashboard, navigate to the **Page Protection** tab and click on **Add Page**. Specify the URL where your page is hosted, and an optional name to help identify the page. After creating the page, you will be guided through the process of installing the monitoring script on your page.

![A screenshot of the Add Page modal in the Evervault dashboard.]()

## Monitoring

Once you have successfully deployed the monitoring script, any third party script or security header changes made on your page are tracked by Evervault. These changes appear inside of the Evervault Dashboard as alerts allowing you to review, approve, and provide a reason for each change that's been detected. You can see all resolved issues in the **Resolved** tab, including the reviewer and reason for the change:

![A screenshot of the Page Protection tab in the Evervault dashboard showing open issues.]()

> Reasons are only required when new scripts are added to the page. However,
>   it's a good rule of thumb to add a reason for the change for auditing purposes
>   if you can identify it.

### Alerting

To receive alerts for changes to your page, enable Page Protection events by navigating to **App → Settings → Webhooks → Create Endpoint**. Slack and standard webhooks are supported. You can subscribe to the following events:

| Event | Description |
| --- | --- |
| `page-protection.scripts.added` | Fires when a new script has been detected on the page. |
| `page-protection.scripts.updated` | Fires whenever a change was detected for an existing script. |
| `page-protection.headers.updated` | Fires whenever a change was detected for security headers. |

## Auditing

All scripts and headers detected are stored for auditing purposes. From each inventory tab, you can export a CSV of all scripts and headers detected.

### Script inventory

Under the **Scripts** view, you can see an inventory of all scripts detected on the page. Click on a script to see its details, including the latest source code, reason for approval, and the history of changes and reviews:

![A screenshot of the Page Protection tab in the Evervault dashboard showing the Scripts view.]()

### Headers

Under the **Headers** view, you can see an inventory of all security headers detected on the page. You can copy the latest headers to your clipboard, or navigate the history of changes:

![A screenshot of the Page Protection tab in the Evervault dashboard showing the Headers view.]()

## Frequently Asked Questions

### Which headers does Evervault monitor?

We only monitor security headers that are used to protect against attacks like XSS and clickjacking:

```text
Content-Security-Policy
Content-Security-Policy-Report-Only
Cross-Origin-Embedder-Policy
Cross-Origin-Opener-Policy
Cross-Origin-Resource-Policy
Permissions-Policy
Referrer-Policy
Report-To
Reporting-Endpoints
Strict-Transport-Security
X-Content-Type-Options
X-Frame-Options
X-Permitted-Cross-Domain-Policies
X-XSS-Protection
```

### Does Page Protection track self-hosted scripts?

Any scripts that are hosted on your own domain are not tracked by Page Protection. This includes any third-party code that is installed via a package manager like npm and bundled with your application.

Since these scripts are part of your static application bundle, they can be analyzed before deployment. We recommend using code analysis tools during your build process to monitor for potential security threats.

OWASP maintains a list of [source code analysis tools](https://owasp.org/www-community/Source_Code_Analysis_Tools).

### Can I enable Page Protection on localhost?

Yes, you can enable Page Protection on localhost. You will need to add the following attribute to your monitoring script tag:

```html
<script src="https://monitoring..." data-local-mode></script>
```

You can also enable debug logs with the following attribute:

```html
<script src="https://monitoring..." data-log-level="DEBUG"></script>
```

### Can I disable proxying for specific scripts?

By default, all scripts are proxied through the monitoring endpoint. This ensures that the scripts running on the page match the versions being analyzed.

However, some scripts may not function correctly when proxied. In such cases, you can use the `data-proxy-bypass` attribute on the monitoring script. This attribute accepts a comma-separated list of script sources that bypass proxying while still being monitored.

```html
<script
  src="https://monitoring..."
  data-proxy-bypass="js.stripe.com,applepay.cdn-apple.com"
></script>
```

### Can I enable Page Protection on specific pages?

Yes, how you enable it depends on how your site is built:

1. **For server-side rendered sites**

Include the monitoring script on **every page** you want to track.

2. **For client-side rendered sites**

You can control monitoring dynamically:

```js
window.EvervaultMonitoring.enable();
window.EvervaultMonitoring.disable();
```

To set whether monitoring is enabled by default on page load, use the `data-default-enabled` attribute in the script tag:

```html
<script src="https://monitoring..." data-default-enabled="false"></script>
```

By default, `data-default-enabled` is set to true, so monitoring starts automatically unless explicitly disabled.

### What should I do if I don't recognize a change?

If you don't recognize a change we've detected, don't resolve the issue just yet. Follow these steps:

- If a new script is added, confirm with your engineering team that the script was meant to be added. If not, another script may have loaded it.
- If a script has been updated, check with the third-party script provider to find out what changes they included. You should also confirm with your engineering team that the change is safe, or if the script should be removed.
- If your security headers have been updated, confirm with your engineering team that the update was expected. If not, your team may need to update their security configuration.

Once you've confirmed the change, include the reason in your review and resolve the issue.