turborfq/bible-local/security.md

Security

Authentication Model

TurboRFQ delegates authentication entirely to MariaDB:

• Credentials (host, port, user, password) are submitted once at login.
• The backend tests them by opening a real PDO connection.
• On success, credentials are stored in a server-side PHP session.
• Every subsequent API request recreates a PDO instance from the session — no credentials are ever cached in the DB layer.

There is no separate application user store. Access control is fully governed by MariaDB's own permission system.

---

What Users Can See and Do

Because every query runs under the session user's MariaDB identity:

• A user sees only the schemas and tables their MariaDB account has SELECT on.
• INSERT/UPDATE/DELETE operations fail at the DB level if the user lacks the corresponding privilege.
• No privilege escalation is possible through the application layer.

---

Session Handling

• Sessions are managed by PHP's default session handler (file-based by default).
• Credentials are stored in $_SESSION and never sent to the browser.
• Session expiry follows PHP's session.gc_maxlifetime setting.

---

SQL Injection Prevention

• All user-supplied values in SELECT, INSERT, UPDATE, DELETE are passed as PDO bound parameters — never interpolated into SQL strings.
• Table and column names are taken from information_schema (not from user input) and used as structural identifiers — they are quoted with backticks where needed.

---

Known Limitations

• No CSRF protection on state-changing endpoints.
• No rate limiting on the login endpoint.
• The PHP built-in server (development mode) has no TLS — do not expose it over a network.