Configuration Security

Who may edit the form and how to protect the configuration: roles, storage lock, and password.

What protects what

Who can open the designer

The Form settings button—and thus the designer—is shown only to authorized users. Who qualifies is determined by the Who should see the "Form settings" button option in the designer under Security (allowedEditorRole). A site owner is anyone with Manage Web permission (manageWeb) on the list.

Actions restricted to site owners (locking storage, setting the designers group, writing the script policy) are marked with the owner only badge in the documentation.

• Do not pick the site's Members or Visitors group, or a group containing all users (Everyone, Everyone except external users), as the designers group: everyone would gain write access to the configuration, and the designer rejects such a choice with a warning when locking.
• The designers group receives write permission only on this list's configuration folder. Group changes take effect in permissions the next time an owner saves the form. If the group does not exist on the site, the designer warns you.

Locked configuration storage

The form configuration is stored in SiteAssets/FormCustomizer/<list id>/config.json. The editor role alone would not protect it from direct modification via SharePoint, because anyone with write access to the site (such as a member with Edit permission) could overwrite the file in the library. That is why the storage lock exists.

Locking sets permissions on the root FormCustomizer folder so that:

• permissions are copied from the site and write access is removed from other users;
• site owners and the user performing the lock retain Full Control;
• the designers group has write access to its list's subfolder;
• the entire organization and (optionally) guests can read the configuration so the form works for everyone (see Reading the configuration).

The form reads its configuration exclusively from this file. Older storage in the list's property bag and the legacy flat shared file are ignored once locked and are used only for one-time migration in an owner's designer.

How to lock storage

1. Open the designer as a site owner and click Security in the top bar.
2. Under Configuration storage, check the status: Locked (only site owners and the designers group have write access), Unlocked (anyone with Manage Lists can overwrite the configuration), or status could not be determined.
3. Click Lock now. Storage is locked even without other configuration changes.

Storage is also locked automatically the first time an owner saves the form. This list's configuration folder does not need to exist yet: the owner must save the form at least once first.

• If you are not an owner, the button is hidden and the designer displays a PowerShell command that performs the lock for you. Send it to a site owner.
• After saving without a lock, the designer shows a Configuration storage is not locked warning with this command.
• If locking fails and restoring the original permissions also fails, the folder may end up with restricted access. The designer provides a recovery PowerShell command.
• If setting read access for the organization or guests fails, the message indicates who might not be able to read the configuration.

First lock and configuration origin

Before the configuration was locked, any site member could have modified it. Therefore, before the first lock, the owner sees a confirmation dialog summarizing what locking will "seal":

• configuration source: the pre-lock file, when it was saved and who modified it last, or legacy configuration from the list property bag;
• count and names of scripts;
• count and names of buttons with actions;
• number of rules;
• who may edit the configuration and which designers group is set.

Review the summary, especially any scripts (they run for every user). Then choose:

• Confirm, lock and save (or for Lock now: Lock and seal existing file): you trust the current file and lock it as is.
• Cancel: nothing is locked. If the file may not match what you expect, save the form from the designer instead of sealing it, which overwrites the configuration with your draft.

As long as storage is unlocked, opening the designer displays an origin warning: "Configuration storage is not locked – site members may have modified the configuration. Review and save it (this will lock it)."

Reading the configuration

Forms are also opened by people who are not members of any site group. To load the configuration, they need read access to the locked storage. Two toggles in Configuration storage control this:

A missing value means on. If you turn a toggle off, only site group members and users with direct access to the storage can read the configuration. Others will see the form without custom configuration. Changes take effect in permissions when an owner saves the form. The configuration contains only the form definition, never item data.

{
  "securityConfig": {
    "allowedEditorRole": "group",
    "allowedEditorGroup": "Form Designers",
    "configReadAllUsers": true,
    "configReadGuests": false
  }
}

Password editor lock

You can password-protect the designer in the Editor lock section of the Security panel. Once set, opening the designer prompts for the password (Unlock editor button) and shows the password hint if you provided one. Unlocking applies to the current session.

• The password must be at least 3 characters long. Remember to save the form after setting or removing it, otherwise the change will not take effect.
• Only a password hash is stored in the configuration (passwordHash, PBKDF2-SHA-256 with 310,000 iterations and a random salt), never the plaintext password. Legacy SHA-256 hashes (passwordSalt) continue to work.
• The optional hint (passwordHint) is stored and displayed in plaintext. Do not put the password in the hint.

Forgotten password: a site owner can open FormCustomizer/<list id>/config.json in the Site Assets library and remove passwordHash, passwordSalt, and passwordHint from securityConfig. The password cannot be recovered.

Script policy

Custom scripts are disabled by default on the tenant. A tenant administrator enables them by setting allow in the tenant Storage Entity FormCraft365_ScriptsPolicy (the legacy key SpfxFormCustomizer_ScriptPolicy with value enabled is only read if the new key is absent; deny in the new key always disables scripts), once for all sites. A missing or unknown value means disabled. In the designer, this is the Allow custom scripts for entire tenant toggle under Custom scripts in the Security panel. Only an App Catalog administrator can write it; for others, the designer shows a PowerShell command for an administrator. The change takes effect after reloading the form, within 15 minutes at the latest.

• When scripts are disabled, rules, expressions, and non-script button actions continue to run.
• onBeforeSave validation does not run and does not block saving. Use a blockSave rule instead.

Details, policy values, and CSP: Script Policy.

Related pages

• Settings: securityConfig: description of keys.
• Permissions: what each SharePoint role and permission allows in practice.
• Script Policy: enabling scripts at the tenant level.
• Troubleshooting: form does not load, Form settings button missing.
• Script security notice.