Skill

Audit Laravel Applications for Security Vulnerabilities

A Laravel security-audit skill covering 8 audit areas - input validation to deployment config - with severity-classified findings.


80
Spark score
out of 100
Updated last month
Version 13.1.0

Add to Favorites

Why it matters

This asset acts as a specialized Laravel Security Auditor, meticulously analyzing your Laravel 10/11+ applications for security vulnerabilities, misconfigurations, and insecure coding practices. It prioritizes data protection, input validation, authorization, and secure configuration, thinking like an attacker to identify real-world exploit scenarios.

Outcomes

What it gets done

01

Analyze Laravel code for security flaws

02

Audit authentication and authorization flows

03

Validate API security and request handling

04

Assess file upload and database security

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-laravel-security-audit | bash

Overview

Laravel Security Audit

A Laravel security-audit skill covering input validation, authorization, authentication, database, file-upload, API, and deployment-configuration risk with severity-classified findings. Use it for security review of Laravel code or deployment configuration, not for feature implementation or non-security architecture questions.

What it does

Laravel Security Audit analyzes Laravel 10/11+ applications for vulnerabilities, misconfigurations, and insecure coding practices, thinking like an attacker but responding like a security engineer. It always considers a fixed threat model - unauthenticated attackers, authenticated low-privilege users, privilege escalation, mass-assignment exploitation, IDOR (Insecure Direct Object Reference), CSRF/XSS vectors, SQL injection, file-upload abuse, API abuse and rate-limit bypass, session hijacking, misconfigured middleware, and exposed debug information - across eight core audit areas: input validation, authorization, authentication, database security, file-upload handling, API security, XSS and output escaping, and configuration/deployment. A worked example shows the fix for a missing authorization check, where a controller fetches a model by ID without verifying ownership, letting an authenticated user access another user's resource by changing the ID:

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

When to use - and when NOT to

Use this skill when reviewing Laravel code for vulnerabilities, auditing authentication/authorization flows, checking API security, reviewing file-upload logic, validating request handling, checking rate limiting, reviewing .env exposure risk, or evaluating deployment security posture. Don't use it if the project isn't Laravel-based, the user wants feature implementation only, the question is purely architectural with no security angle, or the request is unrelated to backend security. Every finding must be classified by risk - Critical, High, Medium, Low, or Informational - without exaggerating severity, and its behavioral constraints are explicit: don't invent vulnerabilities, don't assume production unless specified, don't recommend heavy external security packages unnecessarily, prefer Laravel-native mitigation, and don't shame the code's author.

Inputs and outputs

Input is Laravel application code, configuration, or deployment settings to audit; output follows a fixed structure per finding - a summary, identified vulnerabilities, a risk level per issue, an exploit scenario where applicable, a recommended fix, and a secure refactored code example when needed. Specific checks include whether APP_DEBUG is disabled in production, whether .env is web-accessible, whether Blade templates use escaped {{ }} output rather than raw {!! !!}, and whether $fillable/$guarded are configured correctly against mass assignment. File-upload review checks MIME-type and extension validation, safe storage paths, public-disk misuse, executable-upload risk, and enforced size limits; API review checks rate limiting, per-user throttling, correct HTTP status codes, hidden sensitive fields, and enforced pagination limits.

Who it's for

Laravel developers and security reviewers auditing an application for vulnerabilities across authentication, authorization, database, file-upload, API, and deployment-configuration risk, who want realistic, severity-classified findings with concrete exploit scenarios and Laravel-native fixes rather than a generic security checklist.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.