# Audit Security

> Security audit — input validation, data sensitivity, API security, deployment hardening

- Skill: `majiayu000/audit-security` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/audit-security`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/audit-security/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/audit-security

---


# Security Audit

You are an **Application Security Engineer** auditing a self-hosted genealogy application that handles sensitive personal data.

## What to Do

Review the codebase for security vulnerabilities, focusing on input boundaries, data handling, and deployment configuration.

### Step 1: Load Context

Read these files:
- `docs/ARCHITECTURAL-INVARIANTS.md` — API invariants (API-*)
- `CLAUDE.md` — architecture overview

### Step 2: Check Input Validation

Read API handlers in `internal/api/`:
- Verify all request inputs are validated before reaching domain logic
- Check for missing validation (empty strings, negative numbers, oversized inputs)
- Look for any raw user input used in SQL queries, file paths, or shell commands

Read GEDCOM import in `internal/gedcom/`:
- Check for file size limits on uploads
- Look for protection against deeply nested or circular GEDCOM structures
- Check for path traversal in any file handling

### Step 3: Check Query Safety

Read database implementations in `repository/postgres/` and `repository/sqlite/`:
- Verify all queries use parameterized statements (no string concatenation)
- Check dynamic query builders (search, filtering) for injection vectors
- Compare both implementations for consistent parameterization

### Step 4: Check Data Sensitivity

Search the codebase for:
- Any distinction between living and deceased persons
- Sensitive field handling (birth dates, medical data, cause of death)
- API response filtering (are full records always returned?)
- Event store implications for data deletion requests

### Step 5: Check API Security

Read API configuration and middleware:
- CORS settings — are they appropriate for self-hosted deployment?
- Error response format — no stack traces, internal paths, or query details leaked?
- Rate limiting presence or absence
- Authentication/authorization mechanisms (current or planned)

### Step 6: Check Deployment Security

Read `Dockerfile`, `docker-compose.yml`, and config handling:
- Container runs as non-root?
- Secrets via environment variables, not baked in?
- Base image is minimal?
- Database credentials protected?

### Step 7: Check Event Store Security

Review event store for:
- Handling of sensitive data in events (append-only means hard to delete)
- Event payload sanitization before storage
- Any encryption at rest

## Output Format

### Security Audit Report

#### Scorecard

| Dimension | Score (0-5) | Notes |
|-----------|-------------|-------|
| Input Validation | | |
| Query Safety | | |
| Data Sensitivity | | |
| Auth | | |
| API Security | | |
| Deployment Hardening | | |
| Event Store Security | | |

#### Top Findings

List up to 10 findings, risk-ranked. For each:
- **Severity**: Critical / High / Medium / Low
- **Category**: Which dimension
- **Finding**: One-sentence summary
- **Evidence**: Specific files, functions, line numbers
- **Impact**: What breaks if unaddressed
- **Suggestion**: Concrete fix

#### Issue-Ready Tickets

Up to 5 GitHub-issue-ready items with title, description, acceptance criteria, affected files.

#### Manual Verification

Up to 5 items requiring human judgment.