# 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.