Security

This page covers hardening recommendations for a production Inventorix deployment, authentication security features, the audit trail, and how to report vulnerabilities privately.

Production hardening checklist

Work through these items before exposing an instance to the internet.

Application environment

Setting	Required value	Notes
APP_ENV	production	Enables production-mode optimisations and disables debug helpers
APP_DEBUG	false	Critical. Debug mode exposes stack traces, environment variables, and application secrets to anyone who triggers an error
APP_KEY	32-byte random string	Generate with php artisan key:generate. Never reuse a key across instances
SESSION_ENCRYPT	true	Encrypts session data at rest in the database
SESSION_DOMAIN	your hostname	Locks session cookies to your domain, preventing cookie theft across subdomains
LOG_LEVEL	warning or error	Reduces log volume; avoids writing user data to disk unnecessarily

# Generate a fresh application key
php artisan key:generate

Danger

Never deploy with APP_DEBUG=true in production. Debug pages render the full .env contents and exception traces in the browser, making secrets trivially extractable.

HTTPS and reverse proxy

Run Inventorix behind a TLS-terminating reverse proxy (nginx, Caddy, Traefik, a cloud load balancer). The application itself does not terminate TLS.

• Redirect all HTTP traffic to HTTPS at the proxy level.
• Set APP_URL to the https:// URL so generated links and redirects use the correct scheme.
• Pass the X-Forwarded-For and X-Forwarded-Proto headers so Laravel can detect the real client IP and scheme.

Secret management

• Do not commit .env to version control. The repository’s .env.example exists as a template only.
• In container deployments, inject secrets as environment variables from a secrets manager (Docker secrets, Kubernetes secrets, Vault, AWS Secrets Manager, etc.) rather than baking them into images.
• Rotate APP_KEY with care: changing it invalidates all encrypted sessions, signed URLs, and encrypted model attributes simultaneously.

Database and Redis

• The database server should not be directly reachable from the public internet. Place it on an internal network segment.
• Redis (used by Horizon and the cache) should likewise be inaccessible from outside the application network. Set a strong Redis password via REDIS_PASSWORD and ensure the Redis port is not exposed.

Horizon dashboard access

Caution

In the current release, the Horizon dashboard at /horizon is accessible to any authenticated Inventorix user. The gate in HorizonServiceProvider returns true for any non-null user:

Gate::define('viewHorizon', function ($user = null) {
    return $user;  // any authenticated user passes
});

This is a known limitation. Restrict access by overriding the gate to check for an admin role or a specific email allowlist before going to production:

Gate::define('viewHorizon', function ($user = null) {
    return $user && $user->is_admin; // replace with your actual role check
});

Until the gate is tightened, consider restricting the /horizon path at the reverse proxy level (IP allowlist, HTTP basic auth, VPN requirement).

Authentication security

Multi-factor authentication

MFA is supported and can be enforced per-user or site-wide. See Authentication configuration for how to enable and enforce it.

Enforce MFA for all admin accounts, particularly any account with access to the Horizon dashboard.

SSO via Microsoft Entra ID

Inventorix supports SSO through Microsoft Entra ID (formerly Azure AD). SSO eliminates password reuse risk and centralises authentication policy (Conditional Access, MFA enforcement, account deprovisioning) in your identity provider.

To enable SSO, set the following in .env:

MS_LOGIN_ENABLED=true
MS_CLIENT_ID=<your-app-client-id>
MS_CLIENT_SECRET=<your-app-client-secret>
MS_TENANT_ID=<your-tenant-id>
MS_REDIRECT_URI=https://<your-host>/auth/microsoft/callback

See Authentication configuration for the full setup walkthrough.

Per-user login access

Individual user accounts have a login_enabled flag. Disabling this per-user flag immediately revokes the user’s admin panel access by gating the canAccessPanel check, without requiring you to delete the user or change roles. Manage this in the admin user panel.

Audit trail

Inventorix records user actions using spatie/laravel-activitylog. The audit log captures who did what and when, across all significant model operations.

Log entries are stored in the database and visible to administrators in the Activity Log section of the admin panel.

Records older than 365 days are pruned when you run php artisan activitylog:clean. Consider adding this command to a scheduled cron if long-term retention is not required; alternatively, archive old records to cold storage before pruning.

See Operations & maintenance for full details on the activity log and log-level configuration.

Vulnerability reporting

Inventorix follows a coordinated disclosure process. Do not open a public GitHub issue for security vulnerabilities.

Report privately via one of:

• GitHub private advisory (preferred): https://github.com/NoiXdev/inventorix/security/advisories/new
• Email: security@noix.dev

Include a description of the issue, its potential impact, reproduction steps or a proof-of-concept, and the affected version (commit SHA or release tag).

Response timeline

Milestone	Target
Acknowledgement	Within 3 business days
Initial assessment and severity rating	Within 7 business days
Fix and coordinated disclosure timeline	Communicated after triage

Supported versions

Only the latest minor release receives security fixes. Upgrade before filing a report against an older version.

The full security policy is published at https://github.com/NoiXdev/inventorix/blob/main/SECURITY.md. That policy also defines in-scope and out-of-scope vulnerability categories, so please consult the full SECURITY.md for scope details before reporting.