Script Attack Protection

What you'll learn:

• What Script Attack Protection does and why it matters
• How Knack's allowlist decides what code is permitted
• Which parts of your app stay protected no matter how this setting is configured

What Script Attack Protection Does

Anywhere your app accepts free-form input — form submissions, rich text fields, imported data — there's a risk that someone could try to sneak in executable code instead of ordinary text. This is known as a script injection attack, and it can be used to steal data, hijack sessions, or manipulate your app's behavior for other users.

Script Attack Protection defends against this by screening custom code elements against an allowlist before they're saved. Anything that isn't on the allowlist is sanitized — stripped out — rather than stored, so it never has a chance to run.

Tip: Keep this setting enabled unless you have a specific, well-understood reason to disable it. It's one of the simplest ways to reduce your app's exposure to injection-based attacks.

How Sanitization Works

When Script Attack Protection is enabled, any content containing HTML tags, attributes, or schemes that fall outside Knack's allowlist is automatically cleaned before it's saved to your database. The disallowed portions are removed; the rest of the content is preserved.

The Allowlist

Knack maintains a list of HTML tags, attributes, and schemes that are considered safe and are permitted even while Script Attack Protection is turned on. This allowlist is what makes it possible to still use legitimate formatting (like rich text) without opening the door to malicious code.

Note: Script Attack Protection does not apply to the API & Code section of your app. It also does not restrict Rich Text views — scripts entered there continue to be allowed even while this setting is enabled.

Tip: If you're using a code element that isn't on the allowlist above and you'd like it added, contact the Knack support team through the chat widget in the Builder.

Examples

• <script src="google.com">Hello world!</script>
  Saves as having no value.
  Why? The<script></script> tag is code that is not on our allowlist.

• <b onclick="alert('hello')">Hello world!</b>
  Saves as <b>Hello world!</b>
  Why? The "onclick" portion is code that is not on our allowlist.

• <b>Hello world!</b>
  Saves as <b>Hello world!</b>
  Why? This HTML code is allowed.

Restricted Areas

Some parts of your app are always protected, regardless of whether Script Attack Protection is enabled or disabled:

• Account details
• Table names
• Field names
• Page elements

These areas never accept executable code, so you don't need to rely on the Script Attack Protection setting to keep them safe.

Warning: Disabling Script Attack Protection removes sanitization for everything outside the restricted areas above. Only do this if you fully understand the trade-off, and consider re-enabling it as soon as your specific use case is resolved.