slopsec

Solid

Security audit and hardening for vibe-coded SaaS apps. Use when reviewing, securing, hardening, or pen-testing an app — especially AI-generated / vibe-coded / "shipped fast" projects (Next.js, Supabase, Firebase, Express, serverless). Triggers: "is my app secure", "security review", "harden this", "check for vulnerabilities", "I'm about to launch", "audit before deploy", "exposed secrets", "leaked API keys", "before I ship". Walks the 50 most common ways vibe-coded apps get owned and produces a prioritized fix list.

API & Backend 16 stars 1 forks Updated 3 days ago MIT

Install

View on GitHub

Quality Score: 80/100

Stars 20%
41
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# slopsec Security review built for **vibe-coded SaaS slop**: apps shipped fast with AI assistance, where the gap between "it works" and "it's safe to expose to the internet" is where attackers live. The premise of the source material is simple — a freshly launched app got probed by an attacker within 3 hours. Bots scan the whole IPv4 space constantly; "nobody knows my URL yet" is not a defense. This skill turns 50 recurring failure modes into a repeatable audit. Use it to **review** existing code or **harden** before a launch. ## How to use this skill 1. **Scope it.** Identify the stack (frontend framework, backend, database, auth provider, hosting) and where secrets live. Most slop vulns cluster around Supabase/Firebase rules, missing server-side authz, and leaked env. 2. **Run the audit.** Walk every item in `references/checklist.md`. For each, either confirm it's handled or flag it. Don't skip categories because the app "looks fine" — the dangerous bugs are invisible from the UI. 3. **Prove the findings.** Where safe and authorized, demonstrate the issue (e.g. fetch another user's row via the API, hit an admin route unauthed, grep the built JS bundle for secrets). A demonstrated bug gets fixed; a theoretical one gets argued about. 4. **Prioritize.** Score each finding by `references/severity.md`. Lead with the catastrophic, instantly-exploitable ones (exposed creds, missing authz, open DB rules). Don't bury a P0 IDOR under a missing security...

Details

Author
lachydotmcg
Repository
lachydotmcg/slopsec
Created
1 months ago
Last Updated
3 days ago
Language
N/A
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

security-audit

Run a full security, bug, and data-protection audit on any codebase (especially vibe-coded apps built with Lovable, Bolt, Replit, Cursor, v0, Claude Code, or similar AI builders). Use whenever the user asks to "audit", "check for vulnerabilities", "find security issues", "review for bugs", "pentest", "rate/score my app's security", "is this safe to launch/deploy", or similar, or before any deployment/launch discussion. Runs 100+ checks across OWASP Top 10 2025, OWASP LLM Top 10, supply-chain, secrets, data protection, auth, and business logic, cross-references live threat intelligence via web search, and produces a scored report (0-100 per category + overall letter grade) with concrete fixes.

0 Updated 1 weeks ago
hemant-datascientist
API & Backend Listed

security-review

A focused, single-lens security review of a change. The one specialist a user runs alone when they care about exploitability — not a general sweep. Core method is taint tracing - follow untrusted input from its source, across the trust boundary, to a dangerous sink - and prove the path is reachable before calling it a finding. Covers injection (SQL/NoSQL/command/LDAP), XSS, SSRF, path traversal, insecure deserialization, authn/authz gaps (missing permission checks, IDOR), secret handling, sensitive-data exposure in logs/errors/URLs, crypto misuse, and unsafe defaults. Every finding cites file:line, a severity (a real exploit path is a blocker), the concrete attack, and a fix.

0 Updated today
itzikiusa
DevOps & Infrastructure Solid

appsec

Application-level security review: dependency manifests for known-vulnerable packages, missing HTTP security headers, permissive CORS configuration. Use when user says 'review my dependencies', 'check for vulnerable packages', 'run a dependency audit', 'audit security headers', 'review CORS config', or when working in package.json/package-lock.json, go.mod/go.sum, requirements.txt/poetry.lock, Gemfile.lock, Cargo.toml/Cargo.lock, pom.xml, or server/app config with CORS or header middleware.

6 Updated 4 days ago
anmolnagpal