When you create a LintLiot instance withDocumentation Index
Fetch the complete documentation index at: https://docs.lintliot.com/llms.txt
Use this file to discover all available pages before exploring further.
createLintliot, you pass a configuration object that controls how the SDK behaves — which modules are active, how aggressively it blocks, and how it handles errors. This page documents every configuration option with its type, default value, and when to change it.
Core options
Your app’s API key from the LintLiot dashboard. The SDK throws at initialization time if this is missing.
The LintLiot API endpoint. Override this only if you are on an Enterprise plan with a dedicated API endpoint.
The environment the SDK is running in. In
development or staging, events are tagged so they appear separately in the dashboard and do not affect your Security Score.What to do if the SDK encounters an unexpected error during request processing.
true— allow the request through and log the error. Recommended for production to avoid taking your app down if LintLiot has an issue.false— throw the error, letting your framework’s error handler return a500.
What to do if the permission API is unreachable during an authorization check.
false— allow the request (fail open). Recommended unless your app handles highly sensitive operations.true— deny the request with a503response.
Enable verbose console logging from the SDK. Useful during local development to see which checks are running and what they return. Disable in production to avoid log noise.
Enable or disable the anomaly detection engine globally. When enabled, the SDK tracks request patterns per IP and user and flags traffic that deviates significantly from the learned baseline.
Fraction of allowed-request events to forward to the LintLiot API, from
0 (none) to 1 (all). Blocked requests and anomaly events are always sent regardless of this setting.Reduce this on very high-traffic apps to lower the volume of events without losing security visibility.Module toggles
Themodules object lets you enable or disable individual protection modules. All modules are enabled by default.
Web Application Firewall. Matches incoming request paths, query strings, and bodies against 150+ regex patterns covering SQLi, XSS, SSRF, path traversal, command injection, and more.
Rate limiting. Enforces per-IP request limits. During and after the 7-day learning phase, thresholds are relative to your app’s observed traffic baseline rather than a fixed number.
Bot detection. Scores each request across 12 browser fingerprint signals including TLS fingerprint entropy, header order, User-Agent consistency, and headless browser markers.
Anomaly detection engine. Tracks per-IP and per-user request rates, data access volumes, and authentication failures. Triggers alerts or blocks when activity exceeds learned thresholds.
Anomaly thresholds
Override the default anomaly detection thresholds to tune sensitivity for your app’s usage patterns:Number of authentication failures from the same IP within 60 seconds before a brute force event is triggered. The default triggers after 3 failures.
Override the data exfiltration threshold — the number of records returned per API response in a 5-minute window that triggers an alert. If not set, the threshold is calculated from your app’s learned
dataAccessMean + 3 * dataAccessStddev baseline.Route sensitivity rules
LintLiot automatically applies extra protection to routes matching built-in patterns (/admin*, /delete*, /export*, /payment*, /billing*, /bulk*, and others). You can add your own custom patterns:
A map of route patterns to protection levels.
Patterns use prefix matching.
| Level | Behavior |
|---|---|
critical | Blocks unauthenticated requests with 403. Audits all access. |
high | Audits all access and logs to the event pipeline. |
medium | Logs access for monitoring. |
low | Informational logging only. |
/admin* matches /admin, /admin/users, and /admin/settings.Lockdown bypass paths
During Emergency Lockdown, the SDK blocks all write operations and restricts traffic. UselockdownBypass to exempt specific paths — such as health checks — from lockdown restrictions:
An array of path prefixes that remain accessible during Emergency Lockdown. These paths bypass all lockdown restrictions. Keep this list minimal — it is the only surface that stays open during an active threat.
Protect options
When you calllintliot.protect(), you can pass per-invocation options to override the global config for that middleware mount:
Rate limit configuration for this middleware mount. Overrides the SDK-level rate limiter.
windowMs— time window in milliseconds (default:60000)max— maximum requests per window per IP (default:100)perUser— also enforce per authenticated user (default:false)strategy—"fixed-window","sliding-window-log","sliding-window-counter", or"token-bucket"(default:"sliding-window-counter")ddosThreshold— auto-block an IP if its requests per second exceeds this value (default:50)
WAF enforcement mode.
block— matching requests are blocked with403.monitor— matching requests are logged but allowed through. Useful during initial rollout to observe what would be blocked.off— WAF is disabled entirely for this middleware mount.
Whether to run bot detection scoring for this middleware mount.
Whether to check IPs against the global blocklist and per-app IP rules.
Whether to run the anomaly detection engine for requests passing through this middleware.
Inject security response headers. Pass
true for defaults, or an object to customize individual headers. Available options: csp, hsts, frameOptions, xssProtection, noSniff, referrerPolicy, permissionsPolicy, coop.Path prefixes to exclude from all protection checks for this middleware mount. The request passes straight through to the next handler. Use this for health check endpoints that must always return
200.A permission string that the authenticated user must hold to pass this middleware. Requires the user ID to be present in the request (via JWT, Clerk, Passport, or
x-user-id header). Returns 403 if the permission check fails.