Security

Defense-in-depth security for sensitive customer data in regulated environments.

Overview

InnConnect handles customer conversations, personal data, and AI-generated content for organizations operating under GDPR, ISO 27001, NIS2, and sector-specific regulations. Every layer of the platform is designed with the assumption that it will be attacked.

Security controls operate at three levels — infrastructure, application, and AI — to provide defense in depth. A vulnerability in one layer does not compromise the system, because the next layer catches it. For compliance framework mapping, see the Compliance page.

Tenant Isolation

Tenant isolation is the foundational security measure in InnConnect. Every other control depends on it. A bug in one tenant's data handling cannot affect another tenant, because their data is physically separated at every layer.

Authentication

Admin panel access requires email and password authentication via Laravel Sanctum. Plain-text passwords are never stored, logged, or transmitted after initial hashing.

• Password hashing — bcrypt with an appropriate cost factor. Passwords are hashed before storage; the original is immediately discarded.
• Session-based auth — Authentication state is maintained via server-side sessions, not JWTs or stateless tokens. This enables immediate session invalidation on logout or deactivation.
• Secure cookies — The session cookie is HTTP-only (not accessible via JavaScript), Secure (transmitted only over HTTPS), and SameSite=Lax (prevents CSRF via cross-origin requests).
• Session rotation — The session token is regenerated on every login to prevent session fixation attacks.
• Failed login logging — Failed attempts are recorded with the email, IP address, and timestamp. Repeated failures trigger rate limiting (see below).

Two-Factor Authentication

All admin users can enable TOTP-based two-factor authentication. When enabled, login requires both a valid password and a 6-digit time-based code from an authenticator app (Google Authenticator, Authy, 1Password, or any TOTP-compatible app).

Setup process

1. Navigate to Profile → Security.
2. Click Enable Two-Factor Authentication.
3. Scan the QR code with your authenticator app. The QR encodes a standard otpauth:// URI with the account name and secret.
4. Enter the 6-digit verification code displayed by the app to confirm setup.
5. Download your recovery codes and store them in a secure location (password manager, printed in a safe).

Recovery codes

During 2FA setup, eight single-use recovery codes are generated. Each code can be used exactly once to bypass 2FA if you lose access to your authenticator app.

• Recovery codes are hashed before storage — InnConnect cannot display them after initial generation. If you lose them, you must regenerate a new set.
• Regenerating recovery codes invalidates all previously generated codes.
• After all 8 codes are consumed, you must regenerate recovery codes from your security settings to get new ones.

Force Password Change

New users invited to the platform receive a temporary password via email. The system forces a password change on first login before the user can access any other admin panel functionality. This ensures temporary credentials have a minimal window of exposure.

• Enforced before all other actions — The password change middleware runs before any route, including API endpoints. There is no way to use the platform with a temporary password.
• Strength requirements — New passwords must meet the configured minimum length and complexity rules. Passwords are checked against a list of commonly breached passwords.
• Temporary password cannot be reused — The new password must differ from the temporary one.

Session Management

Sessions are stored server-side in the PostgreSQL system database — not in cookies, not in Redis. The cookie contains only an opaque session token. This prevents client-side tampering and makes server-side session invalidation take effect immediately.

Rate Limiting

All sensitive endpoints are rate-limited to prevent brute force attacks, API abuse, and excessive AI credit consumption. Rate limits are enforced at the application layer using Laravel's built-in throttle middleware. Each limit is keyed to prevent one user's limit from affecting another.

When a rate limit is exceeded, the server returns HTTP 429 Too Many Requests with a Retry-After header indicating when the limit resets. Repeated violations are logged to the security audit log with the offending IP and identity.

Input Validation

All data submitted to InnConnect — through admin panel forms or API endpoints — is validated server-side before processing. Client-side validation exists as a UX convenience; it is never trusted for security decisions.

• Strict type and format rules — Every form field is validated against explicit type, length, and format constraints defined in Laravel Form Request classes.
• Mass assignment prevention — Controllers use $request->validated() or $request->only([...]) to whitelist accepted fields. Raw $request->all() is never passed to models or services.
• File upload validation — Uploaded files are validated for MIME type (by content inspection, not just extension), maximum size, and allowed extensions. ClamAV scans files for malware before storage.
• Integer bounding — Numeric parameters (pagination offsets, IDs) are cast and bounded before use in database queries to prevent injection and out-of-range errors.

XSS Protection

Cross-Site Scripting is mitigated through two independent sanitization layers. If one layer fails, the other catches it.

In addition, Blade templates use double-curly-brace escaping by default, which HTML-encodes output. Unescaped output is used only when content has already passed through HTMLPurifier, and these usages are tracked and audited.

SSRF Protection

The KB Wizard allows admin users to provide external URLs for content scraping. Without validation, this creates a Server-Side Request Forgery (SSRF) vector — an attacker could trick the server into making requests to internal infrastructure, cloud metadata endpoints, or other restricted resources.

The UrlValidator service validates every URL before any outbound HTTP request is made. It blocks:

Blocked URL attempts are logged to the security audit log with the requesting user's identity, the rejected URL, and the reason for rejection.

Prompt Injection Defense

The AI chat pipeline processes content from three external sources: Knowledge Base articles, scraped web pages, and end-user messages. Any of these could contain malicious text designed to override the AI's instructions — a class of attack known as prompt injection.

InnConnect uses structural defenses rather than content filtering. Content filtering (e.g. blocking the phrase "ignore all previous instructions") is fragile and easily bypassed. Structural separation is robust.

• XML-style delimiters — KB content is wrapped in <knowledge_base_context> tags. User messages are wrapped in <user_message> tags. The AI is instructed to treat content within these tags as reference data only, never as instructions.
• Instruction reinforcement — After external content is injected into the prompt, the system prompt reinforces the AI's core behavioral directives. This reduces the effectiveness of any injected override, because the reinforcement is positioned after the attack surface.
• Content sanitization — The ContentSanitizer service detects and flags known injection patterns in scraped and user-submitted content before it enters the prompt. Detected patterns are logged but not silently removed (which could break legitimate content).

CSRF Protection

All state-changing form submissions in the admin panel include a Laravel CSRF token (@csrf). Requests without a valid token are rejected with HTTP 419.

• All 24 POST forms verified — The automated test suite confirms that every POST form in the admin panel includes CSRF protection.
• API endpoints exempt — The chat widget API uses session-based token authentication, not cookies. Since CSRF exploits rely on the browser automatically sending cookies, token-authenticated endpoints are not vulnerable to CSRF.
• Webhook signature verification — Stripe webhooks are verified by cryptographic signature using the Stripe SDK before processing. Invalid signatures are rejected and logged.

Content Security Policy

InnConnect serves a Content Security Policy (CSP) header on all admin panel responses. The CSP restricts which resources can be loaded and executed in the browser.

• Inline script policy — Inline scripts are allowed via unsafe-inline because the application uses server-rendered inline scripts with dynamic PHP data. XSS is mitigated by Laravel's auto-escaping and the ContentSanitizer service.
• Style restriction — Inline styles are allowed via unsafe-inline. External stylesheets are loaded from the application origin and explicitly allowlisted CDN sources.
• CDN allowlisting — External resources (CDN fonts, libraries) are explicitly allowlisted by origin.
• Clickjacking prevention — The frame-ancestors directive prevents the admin panel from being embedded in iframes on other domains.
• HSTS in production — Strict-Transport-Security ensures browsers always connect over HTTPS after the first visit.

Security Headers

The following HTTP security headers are set on all admin panel responses by the SecurityHeaders middleware.