What's changing?

• We will no longer support adding scripts to forms except via Themes.

• We will no longer support in-line event handlers on forms (note: event handlers added via scripts are not restricted).

• We will require that all scripts referenced in Themes include a "justification" for the usage of the script.

• We are updating our Content Security Policy to restrict certain unsafe actions by scripts.

When will these changes take effect?
These changes will take effect starting on October 16th, 2025. At that time, any scripts or event handlers not referenced in a Theme and without a provided justification will no longer load. Your forms will otherwise continue to function as usual, but they may appear or function unexpectedly if they rely on content powered by scripts or event handlers that are no longer supported.

Why is this happening?
The newest PCI requirements are intended to ensure that payment information online is secure, and to prevent fraudulent uses of credit cards. These requirements require that any code running on any pages accepting payment information must be justified with a brief reason for using that code, must be tracked, and must be checked to ensure that the code has not been altered.

We are making these changes to our forms in order to comply with these requirements and ensure that our forms protect both you and your supporters, while also maintaining the flexibility of EveryAction forms that you rely on. While these changes may be inconvenient, they are necessary to keep up with the evolving landscape of fraud patterns online, and for us to continue providing you with secure tools.

What do I need to do by October 16th?

• Audit your EveryAction forms that are hosted by EveryAction

• Remove any in-line event handlers

  • Replace in-line event handlers with native Online Actions functionality, or event handlers in Themes

• Remove any custom JavaScript or <script> tags referenced directly in WYSIWYG/HTML components in the Online Actions formbuilder

  • Note: we let you know via email if you have any forms with JavaScript referenced directly in the WYSIWYG/HTML components, so reference the email we sent you - if this isn’t mentioned in it, then we only identified scripts in your Themes and/or Reusables.

• Audit your Themes and Reusables

  • Add a "justification" for any scripts in your Themes and Reusables

  • Ensure all Reusables that include scripts are loaded on your forms via a Theme

How should I do this, step by step?

1. Consider where you load your forms - if supporters only access your forms when they’re embedded on your site, then you can ignore items 3 and 4, as they won’t impact forms embedded on other sites. If supporters access your forms on secure.everyaction.com or on vanity domains that we set up, then complete items 2-5.

2. Consider deactivating forms, Themes, and Reusables that you’re no longer using to limit the scope of changes you need to make.

3. Pull up your list of Reusables in Online Actions

   1. Move any event handlers in your Reusables into scripts

   2. For any scripts, add a ‘data-script-justification' attribute to the script tag and provide a brief reason for using the script as the value for that attribute

   3. Update any Reusables that include scripts to be loaded via a Theme rather than directly in your form WYSIWYG/HTML components

   4. Since any scripts in the WYSIWYG editor within a Reusable will be blocked, consider removing the WYSIWYG editor for any Reusables that need custom scripts

4. Pull up your list of Themes in Online Actions

   1. Move any event handlers in your Themes into scripts

   2. For any scripts, add a ‘data-script-justification' attribute to the script tag and provide a brief reason for using the script as the value for that attribute

5. If we let you know via email that you have forms with JavaScript referenced directly in the WYSIWYG/HTML components: Remove scripts from the WYSIWYG/HTML components on individual forms and add them to Themes instead, including a justification

What are the new PCI requirements?

There are two key new requirements in PCI DSS v4.0.1:

• 6.4.3 mandates script authorization, integrity assurance, and an inventory with written justification

• 11.6.1 mandates change/tamper detection that evaluates the received page and headers and alerts, running on a regular cadence

You can read the full requirements here if you’d like more detail.

These requirements went into effect in March of 2025, but clarity around their application to organizations using third-party hosted elements has only recently emerged.

Which forms are affected and which aren’t?

These changes impact all forms (not just contribution forms) hosted by EveryAction. This includes:

• Forms loaded on secure.everyaction.com

• Forms loaded on vanity domains that you set up with EveryAction

These changes do not impact forms that you embed on your own website - any scripts you load on embedded forms will be unaffected by our changes. However, keep in mind that you’re responsible for meeting PCI requirements on your own site.

Why are all form types, not just contribution forms, impacted?

We’re making these changes across the domains that we manage to ensure that we are fully compliant with the latest PCI requirements and are also ensuring the security of you and your supporters' data. These changes help protect against web scraping via JavaScript, which is an increasing form of fraud that can impact more than just payment data.

Can we still use third party scripts and event handlers?

Yes—with controls. As long as you add event handlers through a script, and as long as all scripts are referenced through a Theme and include a justification, you can continue to use these tools to customize your forms.

However, scripts that use unsafe-eval will be blocked. Many third-party libraries have workarounds for this.

The most common example is Google Tag Manager, and you can find their guidance here: Use Tag Manager with a Content Security Policy  |  Tag Platform  |  Google for Developers.

As regulations evolve and are clarified, we may revise our policy, but we’ll notify you of any additional changes that might impact your forms.

What is a ‘justification’ for a script and how do I include it?

A justification is just a brief reason for using each script. For example, if you’re loading Optimizely via a script, your justification might be “A/B testing to optimize form performance.” If you’re loading Google Tag Manager, your justification might be “Tracking form performance analytics.”

The purpose of a justification is to ensure that all scripts loading on your forms are intentional, making it easier to identify if there are any unexpected and harmful scripts present.

You should add a justification by adding a ‘data-script-justification' attribute to the script tag and providing a brief reason for using the script as the value for that attribute.

Here’s an example:

<script data-script-justification="Customize form layout">
// Implementation of an alterFormDefinition Callback
var alterFormTitle = function(args) {}
// etc
</script>
 <script data-script-justification="A/B testing framework" type="text/javascript" src="//cdn.optimizely.com/js/10101010101.js"></script>

What if I need a script in a Reusable?

You can include a script in a Reusable as long as it includes a justification and the Reusable is loaded on your form via a Theme.

What happens if I don’t update my forms by October 16?

Non-compliant scripts and handlers won’t load. Your forms will most likely still function for core submission, but any display or behavior that depended on unsupported code may be missing or behave differently.

Where can I get help if I need it?

Contact Support for assistance. We recommend including specific examples with your questions to ensure we’re able to assist quickly and clearly.

Should we expect any other changes, and how can we get ahead of them?

We have rolled out an initial, report-only version of the changes to our Content Security Policy that we are using to gather data on the impact of these planned changes. Based on that data and our ongoing monitoring after these planned changes are live, we will continue to iterate on this policy.

We also continue to follow PCI standards and other industry best practices to prevent fraud and bolster security. We will continue to notify you before any other changes are made that might impact your forms.

Our best recommendation is to follow standard HTML syntax and conventions when adding scripts and event handlers to your forms - the more consistent and standard your code is, the more resilient it will be to any future PCI or security changes.

What is your monitoring process for scripts and will it impact us?

We have already begun internal reporting on script usage on forms and may reach out individually if we see problematic scripts that need attention as we get closer to the timeline for these changes (October 16).

Once we begin restricting script usage, we will continue monitoring and may contact you if we notice that scripts are being consistently restricted on your forms so that you can take action to load these scripts correctly.

How can we verify if we’ve made the changes correctly?

Our Support team can provide a list of your affected themes, reusables, forms, and pages that still require updates. Please note that this list will exclude themes and reusables that contain at least one script and contain at least one justification, but this does not validate that the justifications were added correctly or for all scripts in those themes and reusables.

You can also validate that your forms and pages have been updated correctly via the developer console on those forms and pages in most major browsers. We have currently rolled out a version of these changes in ‘report-only’ mode, meaning that scripts and event handlers are not yet blocked, but there is alerting on what will be blocked when these changes take effect.

• Load the form or page you want to validate

• Right-click and click on ‘Inspect’ or ‘Inspect element’

• In the panel that opens, click ‘Console’

• Review the alerts in the console for lines that start with ‘[Report Only]’ - these alerts will indicate if a script will fail to load once these changes take effect

  • Note that these alerts are logged at the point where the script or event handler would actually be executed, so we recommend walking through your entire form workflow, not just the first page.

Here’s an example of a script that will fail to load once these changes take effect.

Please note that these alerts will not indicate when scripts and event handlers directly in form fields and components (i.e. not loaded via a Theme) will be blocked. As noted above, all scripts and event handlers must be loaded via Themes.