---
title: "Inside LFORLA's Security Architecture"
description: "Row-level security, short-lived sessions, strict CORS and no direct database access — how we harden a benchmarking platform."
updated: 2026-06-19
url: https://lforla.org/blog/lforla-security-architecture
---
Benchmarking platforms hold two things attackers want: large language model prompts and evaluation datasets. This post documents the security model behind LFORLA.

## Defense in depth

- **Zero trust between services.** Every inter-service call carries a JWT. Service identity is verified before any request is processed.
- **No direct database access.** Applications reach PostgreSQL only through a transaction-mode connection pooler, so a leaked connection string can't touch the database directly.
- **Row-level security.** RLS policies are mandatory on every table. A user's query simply cannot see another tenant's rows, even if application code made a mistake.

## Authentication

- Sessions are **short-lived JWTs** with server-side refresh rotation.
- Passwords are hashed with bcrypt (cost factor tuned for the server).
- Multi-factor authentication is enforced for privileged actions, with rate limiting on verification attempts.

## Web application hardening

- Strict **Content-Security-Policy** with no inline script execution.
- `X-Frame-Options: DENY`, MIME-sniffing protection and a restrictive referrer policy.
- **Zod-validated inputs** on every endpoint. Unknown payloads are rejected before reaching business logic.

## Reporting a vulnerability

We treat security reports seriously. Reach the team via the [company page](/company) with details, reproduction steps and proposed fixes.