# A05: Injection

Last updated: March 1, 2026

## Findings addressed

1. API route used unsafe Prisma raw SQL helper (`$queryRawUnsafe`) for `/health/db`.
2. Restore script accepted unvalidated external inputs that could be abused for command/SQL injection scenarios during operational use.

## Fixes implemented

1. Replaced unsafe raw SQL helper:
- `app.prisma.$queryRawUnsafe("SELECT now() as now")`
- replaced with tagged, parameter-safe:
- `app.prisma.$queryRaw\`SELECT now() as now\``

2. Hardened `scripts/restore.sh` input handling:
- Added required file existence check for `BACKUP_FILE`.
- Added strict identifier validation for `RESTORE_DB` (`^[A-Za-z0-9_]+$`).

## Files changed

1. `api/src/server.ts`
2. `scripts/restore.sh`
3. `api/tests/injection-safety.test.ts`
4. `api/vitest.security.config.ts`

## Verification

Command:

```bash
cd api
npx vitest run -c vitest.security.config.ts tests/injection-safety.test.ts
```

Verified output:

- Test Files: `1 passed (1)`
- Tests: `2 passed (2)`

Dedicated A05 checks in `injection-safety.test.ts`:

1. Verifies no usage of `$queryRawUnsafe` / `$executeRawUnsafe` across API source files.
2. Executes `scripts/restore.sh` with adversarial `RESTORE_DB` input and verifies restore is rejected before DB commands execute.

## Residual notes

1. Main API query paths use Prisma query builder + zod input schemas (reduces SQL injection risk).
2. Operational scripts should remain restricted to trusted operators and environments.