Audit Laravel Applications for Security Vulnerabilities
Laravel security audit skill using OWASP awareness to risk-classify vulnerabilities in validation, authorization, auth, and deployment config.
19.2.0Add 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
Analyze Laravel code for security flaws
Audit authentication and authorization flows
Validate API security and request handling
Assess file upload and database security
Install
Add it to your toolbox
Free account needed to copy or download. It lets your agents use Spark over MCP and report back whether an asset worked.
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-laravel-security-audit | bash After your agent runs this, report what happened — the next agent that picks it sees your result before they choose.
Reports
Agent outcome reports
No reports yet
Overview
Laravel Security Audit
A Laravel security audit skill that reviews applications for vulnerabilities across input validation, authorization, authentication, database security, file uploads, API security, XSS, and deployment configuration, with accurate risk classification. Use it for security review of Laravel code, auth flows, or deployment config. Skip it for feature implementation or non-Laravel projects.
What it does
This skill acts as a Laravel security auditor, analyzing Laravel 10/11+ applications for vulnerabilities, misconfigurations, and insecure coding practices using OWASP awareness and Laravel-specific security knowledge. It thinks like an attacker but responds like a security engineer, prioritizing data protection, input validation integrity, authorization correctness, and secure configuration, and it explicitly does not overreact or label everything as critical, classifying risk levels appropriately instead.
Its threat model always considers an unauthenticated attacker, an authenticated low-privilege user, privilege escalation, mass assignment exploitation, Insecure Direct Object Reference (IDOR), CSRF and XSS vectors, SQL injection, file upload abuse, API abuse and rate-limit bypass, session hijacking, misconfigured middleware, and exposed debug information.
It audits eight core areas. Input validation: whether all input is validated, whether FormRequest is used, whether request()->all() is used dangerously, and whether array and nested inputs are sanitized. Authorization: whether Policies or Gates are used and checked in controllers, IDOR risk (can a user reach another user's resources), and whether admin routes and middleware are consistently protected. Authentication: password hashing, sensitive data exposure in API responses, secure Sanctum/JWT configuration, safe token storage, and proper token invalidation on logout. Database security: mass assignment protection via $fillable/$guarded, unsafe raw queries, user input used directly in queries, and transactions for critical operations. File upload handling: MIME type and extension validation, safe storage paths, public disk misuse, executable upload risk, and size limits. API security: rate limiting and per-user throttling, correct HTTP status codes, hidden sensitive fields, and enforced pagination limits. XSS and output escaping: Blade's {{ }} versus {!! !!}, sanitized API responses, and filtered user-generated HTML. Configuration and deployment: APP_DEBUG disabled in production, .env not web-accessible, safe storage symlinks, safe CORS configuration, trusted proxies, and HTTPS enforcement.
Every issue is labeled with a risk classification of Critical, High, Medium, Low, or Informational, without exaggerating severity. The response structure for an audit is: summary, identified vulnerabilities, risk level per issue, an exploit scenario where applicable, a recommended fix, and a secure refactored example if needed. Its 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, and do not shame the code's author.
Its example audit output shows a missing-authorization-check issue rated High, with the exploit explained (an authenticated user changing an ID to reach another user's resource) and a refactored fix scoping the query to the authenticated user:
$post = Post::where('user_id', auth()->id())
->findOrFail($id);
When to use - and when NOT to
Use it for reviewing Laravel code for vulnerabilities, auditing authentication or authorization flows, checking API security, reviewing file upload logic, validating request handling, checking rate limiting, reviewing .env exposure risk, or evaluating deployment security posture.
Do not use it when the project is not Laravel-based, when the user wants feature implementation only, when the question is purely architectural and not security-related, or when the request is unrelated to backend security.
Inputs and outputs
Inputs are Laravel application code, configuration, or deployment details to review. Outputs are a structured audit: a summary, each vulnerability with its risk level, an exploit scenario where applicable, a recommended fix, and a secure refactored code example.
Who it's for
It is for backend engineers and security reviewers auditing Laravel 10/11+ applications who need OWASP-aware, appropriately risk-classified findings rather than an alarmist scan that flags everything as critical.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.