PHP Security Review

3. Analyze Each Category

For each category in the checklist, search the codebase for relevant patterns. Use Grep, Glob, and Read tools to find:

• Raw SQL queries without parameter binding (DB::raw, whereRaw, string concatenation in queries)
• Unescaped output in Blade templates ({!! !!} vs {{ }})
• Missing CSRF protection on forms and state-changing routes
• Mass assignment vulnerabilities (missing $fillable or $guarded)
• Insecure deserialization (unserialize() on user input)
• Dangerous PHP functions (eval, exec, system, shell_exec, passthru)
• File upload without validation (type, size, extension)
• Hardcoded secrets, API keys, passwords in source code
• .env file exposure risks
• Missing rate limiting on authentication endpoints
• Insecure session configuration
• Missing security headers (CSP, X-Frame-Options, HSTS)
• Livewire: exposed properties, missing authorization on actions
• Kirby: panel access, content file permissions, API exposure
• Outdated dependencies with known CVEs

4. Generate the Report

Produce a structured report with these sections:

## Audit Securite PHP - [Project Name]

### Score global
X / Y pratiques conformes (Z%)

### Resume
[2-3 sentences summarizing the main findings]

### Resultats par categorie

#### [Category Name] (OWASP AXX)
| # | Pratique | Statut | Commentaire |
|---|----------|--------|-------------|
| 1 | ...      | OK/KO/NA | ...       |

### Vulnerabilites critiques
[List any findings that could be actively exploited]

### Top priorites
[5-10 most impactful fixes, ordered by risk/effort ratio]

### Recommandations detaillees
[For each KO finding, explain the vulnerability, exploitation scenario, fix, and relevant OWASP category]

Status values:

• OK - Practice is followed
• KO - Practice is not followed (include fix + OWASP reference)
• NA - Not applicable to this project
• PARTIAL - Partially followed (explain what's missing)

5. Prioritization

When listing recommendations, prioritize by exploitability:

1. Critical - Actively exploitable, data breach risk (SQL injection, auth bypass, RCE)
2. High - Exploitable with some effort (XSS stored, CSRF, IDOR, mass assignment)
3. Medium - Exploitable under specific conditions (information disclosure, missing headers)
4. Low - Defense-in-depth improvements (logging, rate limiting, dependency updates)

6. Export the Review Report

Once the audit is complete, save the full analysis as a Markdown document at the root of the audited codebase:

/docs/YYMMDD_php-security-audit.md

Where YYMMDD is the current date (e.g., 260206 for February 6, 2026). Create the /docs/ directory if it does not exist.

The document must include:

1. The complete audit report (as generated in step 4)
2. An action plan section at the end, listing all tasks derived from the findings:
   • Grouped by priority (Critical, High, Medium, Low)
   • Each task broken down into sub-tasks of 2 to 4 hours (assuming AI-assisted development)
   • Time estimate for each sub-task
   • Total estimated time per priority level

### Plan d'action

#### Critique
- [ ] [Tache] — ~Xh (avec IA)
  - [ ] [Sous-tache 1] — ~2h
  - [ ] [Sous-tache 2] — ~3h

#### Haute priorite
...

#### Moyenne priorite
...

#### Basse priorite
...

**Total estime : ~Xh**

Important Notes

• This is a static code audit, not a penetration test. Recommend DAST/pentest for full coverage.
• Focus on what is verifiable in the codebase. Flag what needs runtime testing.
• Be specific: point to exact files, lines, and code patterns.
• For Laravel: leverage framework security features (Eloquent, Blade escaping, CSRF middleware, policies).
• For Kirby: check panel config, blueprint permissions, content API exposure.
• For Livewire: check exposed public properties, action authorization, file uploads.
• When a practice cannot be verified from code alone (e.g., WAF configuration), mark as "needs verification".