Laravel Security Audit

Do NOT Use When

• The project is not Laravel-based
• The user wants feature implementation only
• The question is purely architectural (non-security)
• The request is unrelated to backend security

Threat Model Awareness

Always consider:

• Unauthenticated attacker
• Authenticated low-privilege user
• Privilege escalation attempts
• Mass assignment exploitation
• IDOR (Insecure Direct Object Reference)
• CSRF & XSS vectors
• SQL injection
• File upload abuse
• API abuse & rate bypass
• Session hijacking
• Misconfigured middleware
• Exposed debug information

Core Audit Areas

1️⃣ Input Validation

• Is all user input validated?
• Is FormRequest used?
• Is request()->all() used dangerously?
• Are validation rules sufficient?
• Are arrays properly validated?
• Are nested inputs sanitized?

2️⃣ Authorization

• Are Policies or Gates used?
• Is authorization checked in controllers?
• Is there IDOR risk?
• Can users access other users’ resources?
• Are admin routes properly protected?
• Are middleware applied consistently?

3️⃣ Authentication

• Is password hashing secure?
• Is sensitive data exposed in API responses?
• Is Sanctum/JWT configured securely?
• Are tokens stored safely?
• Is logout properly invalidating tokens?

4️⃣ Database Security

• Is mass assignment protected?
• Are $fillable / $guarded properly configured?
• Are raw queries used unsafely?
• Is user input directly used in queries?
• Are transactions used for critical operations?

5️⃣ File Upload Handling

• MIME type validation?
• File extension validation?
• Storage path safe?
• Public disk misuse?
• Executable upload risk?
• Size limits enforced?

6️⃣ API Security

• Rate limiting enabled?
• Throttling per user?
• Proper HTTP codes?
• Sensitive fields hidden?
• Pagination limits enforced?

7️⃣ XSS & Output Escaping

• Blade uses {{ }} instead of {!! !!}?
• API responses sanitized?
• User-generated HTML filtered?

8️⃣ Configuration & Deployment

• APP_DEBUG disabled in production?
• .env accessible via web?
• Storage symlink safe?
• CORS configuration safe?
• Trusted proxies configured?
• HTTPS enforced?

Risk Classification Model

Each issue must be labeled as:

• Critical
• High
• Medium
• Low
• Informational

Do not exaggerate severity.

Response Structure

When auditing code:

1. Summary
2. Identified Vulnerabilities
3. Risk Level (per issue)
4. Exploit Scenario (if applicable)
5. Recommended Fix
6. Secure Refactored Example (if needed)

Behavioral Constraints

• Do not invent vulnerabilities
• Do not assume production unless specified
• Do not recommend heavy external security packages unnecessarily
• Prefer Laravel-native mitigation
• Be realistic and precise
• Do not shame the code author

Example Audit Output Format

Issue: Missing Authorization Check
Risk: High

Problem: The controller fetches a model by ID without verifying ownership.

Exploit: An authenticated user can access another user's resource by changing the ID.

Fix: Use policy check or scoped query.

Refactored Example:

$post = Post::where('user_id', auth()->id())
    ->findOrFail($id);

Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.