Store security settings
On this page
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 (see User enumeration protection)
:::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. :::
Password reset link expiry
Password reset links are valid for a limited time after they are sent. An expired link cannot be used to change a password.
| Store variable | Default | Description |
|---|---|---|
passwords.reset.within_minutes |
360 |
How long (in minutes) a password reset link stays valid after it is sent. The default of 360 minutes is 6 hours |
How it works:
- The window starts when the reset email is sent. Once it elapses, the link no longer changes the password.
- A customer who follows an expired, already-used, or superseded link is taken to the forgot password form with a message explaining the link is no longer valid, so they can request a fresh link themselves — no support action is needed.
- Requesting a new reset link invalidates any earlier link, even one still inside its window.
- Zero, negative, or non-numeric values are ignored and the default of 360 minutes applies.
See Reset a customer password for the full reset flow and troubleshooting.
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 (the default), new customers must confirm their email before they can log in to their account. When set to a positive number, they can access their account for that many minutes before confirmation is enforced.
The confirmation email is always sent, and email confirmation cannot be turned off entirely. This store variable only controls when an unconfirmed account is blocked from logging in — not whether confirmation is required.
Keep these points in mind:
- Completing a purchase does not require confirmation. A customer can check out and their order is placed whether or not they confirm — the grace period only affects access to the account area afterward.
- The grace period is a one-time countdown that starts when the account is created. It does not reset on each login. Once it elapses, the customer is blocked from logging in until they confirm their email. Their original confirmation link still works, or they can request a new one.
- Setting a large value (for example,
525600for one year) defers the block rather than removing it. After that window passes, an account that still has not been confirmed is locked out at the next login attempt until it is confirmed.
:::tip
A short grace period (for example, 60) reduces checkout friction — a new customer can reach their order confirmation and account immediately after checkout and confirm their email at their convenience within the window.
:::
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_policystore variable. - Report-only: Sends a
Content-Security-Policy-Report-Onlyheader. Policy violations are reported to the browser console but not enforced — no content is blocked. This is the default mode once CSP is enabled, unlesscontent_security_policy_typeis set toenforce. - Enforce: Sends a
Content-Security-Policyheader. 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. :::
User enumeration protection
User enumeration protection prevents attackers from discovering whether a given email address has an account in your store. Without it, an attacker could use your login or password reset form to silently probe email addresses — a different response for “account exists” versus “account does not exist” would let them build a list of your customers’ emails.
This protection is always enabled — it cannot be disabled and requires no configuration.
How it works:
- Forgot password: Whether or not the email is registered, the response is always “You will receive an email with instructions on how to reset your password in a few minutes.” No information is disclosed about whether the account exists.
- Login: Error messages are intentionally generic. An attacker cannot distinguish between a wrong password and a non-existent account, and cannot confirm an account exists by triggering an account lockout message.
:::note This is a platform-level security feature. There are no store variables to configure. :::
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.
Was this article helpful?
Thanks for your feedback! It helps us improve our docs.