Store security settings

StoreConnect provides several security settings that you can configure using Store variables. All settings have safe defaults and are optional.

Account lockout

Account lockout protects customer accounts from brute-force login attempts. After a configurable number of failed login attempts, the account is temporarily locked.

Store variable	Default	Description
passwords.lockout.failed_attempts_threshold	5	Number of consecutive failed login attempts before the account is locked
passwords.lockout.max_duration_minutes	15	How long the account stays locked (in minutes) before automatically unlocking

How it works:

• After the threshold is reached, the account locks and the customer cannot log in until the lockout duration has elapsed
• The account unlocks automatically after the configured duration — no manual intervention is required
• When a customer resets their password, the lockout is cleared immediately
• To protect against account enumeration, the login error message is generic regardless of whether lockout is the cause

:::note Manual admin unlock is not currently supported. If a customer needs immediate access, they can use the password reset flow to clear the lockout. :::

Session timeouts

Session timeouts limit how long a customer session remains active, reducing the risk of unauthorized access on shared devices.

Store variable	Default	Description
session.inactivity_timeout_minutes	30	Minutes of inactivity before the session expires and the customer is logged out
session.absolute_timeout_minutes	60	Maximum session duration in minutes from login, regardless of activity

How it works:

• The inactivity timeout resets with each request. If the customer makes no requests for the configured period, they are logged out.
• The absolute timeout counts from the time of login. Once reached, the session ends even if the customer is actively browsing.
• Both timeouts apply to web browser sessions only. POS sessions are not affected.

To effectively disable a timeout, set it to a very large value (e.g., 999999).

Email confirmation grace period

By default, new customers must confirm their email address before they can log in. You can configure a grace period to allow limited access before confirmation is required.

Store variable	Default	Description
logins.unconfirmed_access_minutes	0	Minutes a newly registered customer can access their account before email confirmation is required

When set to 0, email confirmation is required immediately. When set to a positive number, new customers can browse and check out for that many minutes before being prompted to confirm their email.

:::tip This is useful for reducing friction during checkout — customers can complete a purchase before verifying their email. :::

Content Security Policy

Content Security Policy (CSP) is a store-level security header that controls what resources the browser is allowed to load for your store — including scripts, styles, images, fonts, and frames. CSP is disabled by default — no CSP header is sent unless you configure it using store variables.

Store variable	Default	Description
content_security_policy	(blank — CSP disabled)	Set to a CSP policy string to enable CSP. When blank, no CSP header is sent.
content_security_policy_type	(blank — report-only when CSP is active)	Set to enforce to block violating resources. Leave blank to use report-only mode.

Modes:

• Disabled (default): No CSP header is sent. No policy is applied or reported. This is the default until you set the content_security_policy store variable.
• Report-only: Sends a Content-Security-Policy-Report-Only header. Policy violations are reported to the browser console but not enforced — no content is blocked. This is the default mode once CSP is enabled, unless content_security_policy_type is set to enforce.
• Enforce: Sends a Content-Security-Policy header. Violations cause the browser to block the resource.

To enable CSP, create a store variable with key content_security_policy and set the value to your policy string.

:::tip Start with report-only mode to identify any policy violations before switching to enforce mode. A restrictive policy can block third-party scripts, styles, or images (such as analytics, chat widgets, or CDN-hosted assets). :::

Example permissive policy (suitable for initial testing):

default-src 'self'; script-src 'self' 'unsafe-inline' *; style-src 'self' 'unsafe-inline' *; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' *; media-src 'self' *; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'

:::tip Use a CSP generator such as Report URI’s CSP generator to help build your policy string. :::

For more granular control, you can set HTTP security headers — including Content-Security-Policy, X-Frame-Options, Referrer-Policy, and CORS headers — on a per-page or per-template basis using the Liquid header tag in your theme templates. This allows dynamic policies based on Liquid variables and is useful when a single store-wide policy is too broad or restrictive.