Security Settings
The Security Settings page in the Admin Panel lets you configure network-level restrictions, session management policies, password requirements, and automated protections against authentication attacks.
Navigate to Admin Panel > Security or go directly to /backoffice/settings/security.
IP allowlist and blocklist
Control which IP addresses or ranges can access your SetGet instance.
IP allowlist
When an allowlist is configured, only requests from listed IP addresses or CIDR ranges are permitted. All other requests receive a 403 Forbidden response.
| Setting | Description |
|---|---|
| Enable IP allowlist | Toggle to activate allowlist enforcement |
| Allowed IPs / CIDRs | Comma-separated list of IP addresses or CIDR ranges |
Example allowlist entries:
203.0.113.10
198.51.100.0/24
10.0.0.0/8
2001:db8::/32WARNING
Be careful when enabling the IP allowlist. If you lock yourself out by not including your current IP address, you will need to modify the configuration directly in MongoDB or via environment variables to regain access.
IP blocklist
The blocklist rejects requests from specific IP addresses or ranges while allowing all others.
| Setting | Description |
|---|---|
| Enable IP blocklist | Toggle to activate blocklist enforcement |
| Blocked IPs / CIDRs | Comma-separated list of IP addresses or CIDR ranges |
TIP
The allowlist and blocklist are evaluated in order: allowlist first, then blocklist. If both are enabled, a request must be on the allowlist AND not on the blocklist to proceed.
Admin Panel IP restriction
You can restrict Admin Panel access to a narrower set of IPs than the main application:
| Setting | Description | Default |
|---|---|---|
| Restrict admin access by IP | Apply a separate IP allowlist to /backoffice/ routes | Disabled |
| Admin allowed IPs | IPs/CIDRs that can access the Admin Panel | Empty |
This is useful when you want all employees to access SetGet from any network but limit Admin Panel access to the office network or VPN.
Session management
Configure how user sessions are created, maintained, and expired.
| Setting | Description | Default |
|---|---|---|
| Session timeout (inactive) | Time of inactivity before session expires | 24 hours |
| Session timeout (absolute) | Maximum session duration regardless of activity | 7 days |
| Remember me duration | Extended session when "Remember me" is checked | 30 days |
| Max concurrent sessions | Maximum active sessions per user (0 = unlimited) | 0 |
| Terminate on password change | Invalidate all sessions when a user changes their password | Enabled |
Session timeout behavior
- Inactive timeout: If a user does not make any API requests within this period, their session expires and they must log in again.
- Absolute timeout: Even with continuous activity, the session expires after this duration. The user must re-authenticate.
- Remember me: When a user checks "Remember me" at login, the inactive timeout extends to this value.
TIP
For high-security environments, set the inactive timeout to 1-4 hours and the absolute timeout to 24 hours. Disable "Remember me" or set it to a short duration.
Force logout
Instance administrators can terminate individual user sessions or all sessions for a user from the User Management page. This is useful when:
- A user reports a compromised account.
- An employee leaves the organization.
- You need to enforce a policy change immediately.
Password complexity requirements
Configure minimum standards for user passwords. These apply to local (email + password) authentication only and do not affect OAuth, SAML, or LDAP users.
| Requirement | Description | Default |
|---|---|---|
| Minimum length | Minimum number of characters | 8 |
| Maximum length | Maximum number of characters | 128 |
| Require uppercase | At least one uppercase letter (A-Z) | Disabled |
| Require lowercase | At least one lowercase letter (a-z) | Disabled |
| Require digit | At least one number (0-9) | Disabled |
| Require special character | At least one of !@#$%^&*()-_=+ | Disabled |
| Disallow common passwords | Reject passwords from a known-compromised list | Enabled |
| Password history | Number of previous passwords that cannot be reused | 0 (disabled) |
| Password expiry (days) | Days until password change is required (0 = never) | 0 |
TIP
A password policy of 12+ characters with mixed case, digits, and special characters, combined with a 90-day expiry and 5-password history, meets most enterprise compliance requirements (SOC 2, ISO 27001, NIST 800-63B).
Password change enforcement
When you increase password complexity requirements, existing passwords are not immediately invalidated. You have two options:
| Option | Description |
|---|---|
| Enforce on next login | Users with non-compliant passwords are prompted to change at next login |
| Grace period | Allow a configurable number of days before enforcing new requirements |
Brute-force protection
Automated protection against credential-stuffing and brute-force attacks.
| Setting | Description | Default |
|---|---|---|
| Enable brute-force protection | Activate rate limiting on login attempts | Enabled |
| Max failed attempts | Number of failed login attempts before lockout | 5 |
| Lockout window | Time window for counting failed attempts | 15 minutes |
| Lockout duration | How long the account is locked after max failures | 15 minutes |
| Progressive lockout | Increase lockout duration with repeated violations | Enabled |
| CAPTCHA after failures | Show CAPTCHA after N failed attempts (0 = disabled) | 3 |
How brute-force protection works
- A user (identified by email + IP) fails to log in.
- The failure is recorded in Redis with a TTL equal to the lockout window.
- After reaching the max failed attempts, the account is locked for the lockout duration.
- During lockout, all login attempts for that account are rejected with a clear message.
- If progressive lockout is enabled, the lockout duration doubles with each consecutive lockout event.
- After a successful login, the failure counter resets.
WARNING
Brute-force protection applies to both email+password and LDAP authentication. OAuth and SAML logins are not affected because authentication happens at the identity provider.
IP-based rate limiting
In addition to per-account protection, SetGet applies IP-based rate limiting:
| Setting | Description | Default |
|---|---|---|
| Max login attempts per IP | Maximum login attempts from a single IP per window | 20 |
| IP rate limit window | Time window for counting IP-based attempts | 15 minutes |
| IP block duration | How long the IP is blocked after exceeding the limit | 30 minutes |
This prevents distributed attacks that target multiple accounts from the same IP.
Account lockout policies
| Policy | Description | Default |
|---|---|---|
| Auto-unlock after duration | Accounts unlock automatically after the lockout period | Enabled |
| Admin manual unlock | Admins can manually unlock accounts from User Management | Always available |
| Notify user on lockout | Send an email to the user when their account is locked | Enabled |
| Notify admins on lockout | Send an alert to instance admins when any account is locked | Disabled |
Security audit
The Security Settings page includes a security posture summary that highlights areas needing attention:
| Check | Recommended | Status Indicator |
|---|---|---|
| HTTPS enabled | Yes | Green / Red |
| IP allowlist configured | Recommended | Green / Yellow |
| Brute-force protection active | Yes | Green / Red |
| Password complexity enabled | Recommended | Green / Yellow |
| Session timeout configured | Yes | Green / Red |
| SMTP configured (for lockout notifications) | Yes | Green / Red |
CORS configuration
Control which origins can make cross-origin requests to the SetGet API:
| Setting | Description | Default |
|---|---|---|
| Allowed origins | List of origins permitted for CORS requests | Instance URL only |
| Allow credentials | Whether cookies and auth headers are sent cross-origin | Yes |
TIP
If you use a CDN or custom domain for your frontend, add it to the allowed origins list. Do not use * (wildcard) in production as it disables credential support and weakens security.
HTTP security headers
SetGet sets the following security headers on all responses. These are not configurable through the Admin Panel but are documented here for security auditors:
| Header | Value | Purpose |
|---|---|---|
X-Content-Type-Options | nosniff | Prevents MIME-type sniffing |
X-Frame-Options | DENY | Prevents clickjacking |
X-XSS-Protection | 1; mode=block | Enables browser XSS filter |
Strict-Transport-Security | max-age=31536000; includeSubDomains | Forces HTTPS |
Content-Security-Policy | Restrictive policy | Prevents XSS and injection attacks |
Referrer-Policy | strict-origin-when-cross-origin | Limits referrer information |
Related pages
- Admin Panel Overview — Navigate the Admin Panel
- Authentication Settings — Password policies and login methods
- Login Logs — Monitor login attempts and suspicious activity
- Audit Logs — Track administrative security changes
- User Management — Force logout and unlock accounts