~ You'll understand this in 8 minutes
TL;DR
Scan results are organized by severity: Critical (fix immediately), High (fix today), Medium (fix this week), Low (ongoing improvement). Each finding shows what's wrong, why it matters, and how to fix it. Start with Critical issues, especially exposed secrets and missing database security. Re-scan after fixes to verify.
CheckYourVibe defines security severity levels as a prioritization framework that helps you focus on what matters most. Critical issues can be exploited right now with serious consequences. High severity issues are exploitable but require more effort. Medium issues represent real risks that should be addressed. Low severity findings are best practices and hardening recommendations.
This severity framework aligns with industry standards and is calibrated for vibe-coded applications.
Reading Your Results Dashboard
After your scan completes, you'll see a dashboard summarizing all findings. The most important sections are:
- Summary Score: An overall security rating for quick assessment
- Issue Breakdown: Count of issues by severity level
- Issue List: Detailed findings with explanations and fixes
- Trend: How your security has changed over time (for repeat scans)
Severity Levels Explained
Critical Severity
These issues can be exploited right now with serious consequences. Someone scanning the internet could find and abuse these within hours.
Fix timeline: Immediately (within minutes)
Common examples:
- API keys exposed in frontend code or committed to git
- Database without Row Level Security (anyone can read all data)
- Authentication completely bypassable
- Admin panels accessible without login
High Severity
Serious vulnerabilities that could lead to data breaches or system compromise. These require some skill to exploit but are well-known attack patterns.
Fix timeline: Within 24 hours
Common examples:
- SQL injection vulnerabilities
- Cross-site scripting (XSS) in user inputs
- Weak or missing authentication on sensitive endpoints
- Insecure direct object references (IDOR)
Medium Severity
Security weaknesses that don't immediately lead to compromise but weaken your overall security posture. Often configuration issues.
Fix timeline: Within a week
Common examples:
- Missing security headers (CSP, HSTS)
- Overly permissive CORS settings
- Weak session configuration
- Missing rate limiting on sensitive endpoints
Low Severity
Best practice recommendations that improve security but aren't urgent. These are the "nice to have" items.
Fix timeline: When convenient
Common examples:
- Verbose error messages in production
- Missing subresource integrity on CDN scripts
- Outdated (but not vulnerable) dependencies
- Suboptimal cookie settings
Common Findings and What They Mean
Exposed API Key in Frontend
const stripe = Stripe('sk_live_xxxx...');
What it means: Your secret Stripe key is visible to anyone viewing your website's source code. Attackers can use this to make charges, access customer data, or cause financial damage.
How to fix: Move the key to a server-side environment variable and never expose secret keys to the frontend.
Missing Row Level Security
// Supabase table 'users' has RLS disabled
What it means: Anyone with your Supabase URL and anon key (both are public) can read, update, or delete all data in this table.
How to fix: Enable RLS and create policies that restrict access. See our Supabase RLS guide.
SQL Injection in Query
db.query(SELECT * FROM users WHERE id = ${userId});
What it means: User input is directly inserted into the SQL query. Attackers can manipulate this to access unauthorized data or destroy your database.
How to fix: Use parameterized queries: db.query('SELECT * FROM users WHERE id = $1', [userId])
Prioritizing Your Fixes
| If You Have | Priority Action |
|---|---|
| Critical issues | Stop everything and fix these now. They're actively exploitable. |
| Only High issues | Address today before continuing development. |
| Only Medium/Low | You're in reasonable shape. Fix Medium issues before launch. |
| No issues | Great! Set up regular scans to maintain this. |
After fixing issues: Run another scan to verify your fixes worked. It's common for fixes to be incomplete or to accidentally introduce new issues.
What If I Don't Understand a Finding?
Each finding in your results includes:
- Description: What the issue is in plain English
- Impact: What could happen if exploited
- Location: Exactly where in your code the issue exists
- Fix guidance: Step-by-step instructions to resolve it
- Learn more: Links to detailed tutorials
If you're still unsure, search our blog for the issue type. We have detailed guides for every common vulnerability.
What does Critical severity mean?
Critical severity means the issue can be exploited right now with serious consequences. Examples include exposed API keys, missing database security, and authentication bypass. These need to be fixed immediately, ideally within minutes of discovery.
Should I fix all issues before launching?
At minimum, fix all Critical and High severity issues before launching. Medium issues should be fixed soon after. Low severity issues are best practices that improve security but aren't urgent. Prioritize based on impact and likelihood of exploitation.
What if I get a false positive?
False positives can happen. If you're confident a finding is incorrect, you can mark it as a false positive in your dashboard. However, it's worth double-checking first. Sometimes what looks like a false positive is actually a real issue that's not immediately obvious.
Why did my score change after fixing issues?
Your security score updates based on the current state of your codebase. Fixing issues improves your score. However, the score can also decrease if you introduce new vulnerabilities or if new types of checks are added to the scanner.
:: ::