How to read a security score and what to do about it
A security score is a compressed representation of your app's risk posture at a point in time. It gives you a single number to track over time and compare across scans, but the number itself is less useful than what is behind it. An app that scores 65 because it is missing HTTP headers is in a very different situation from an app that scores 65 because it has an exposed service role key — both scores are the same, but one is a quick configuration fix and the other is a critical incident that requires immediate action. To use a security score productively, you need to understand how it is calculated, what the findings that drive it mean in practice, and how to prioritize fixes when you cannot do everything at once.
Sayver's score starts at 100 and deducts points based on finding severity. Critical findings — typically complete access control failures like a disabled RLS layer covering all tables, or an exposed service role key — deduct 40 points each. High findings deduct 25. Medium findings deduct 10. Low findings deduct 5. Informational findings carry no deduction; they are observations worth knowing but not worth penalizing. The score is calculated per scanner kind: your site score reflects the findings from the live URL scan, and your code score reflects the findings from the source code analysis. This separation matters because they measure different things — a perfect site score with a failing code score means your deployment is configured correctly but your source has vulnerabilities that will eventually surface in production.
When you have multiple findings, the right prioritization order is severity first, exploitability second, and effort third. A critical finding — regardless of how hard it is to fix — comes first, because critical findings represent conditions where an attacker can gain significant access with minimal effort. An exposed service role key is a critical finding because exploiting it requires only the Supabase JavaScript client and the key itself, both of which are available in your page source. Fix critical findings before doing anything else. High findings represent serious vulnerabilities that require slightly more attacker effort or have a somewhat smaller blast radius — missing rate limiting on authentication, for example, enables credential stuffing but requires an attacker to have a credential list, which is a trivially low bar. High findings come second.
Medium findings are the most commonly misunderstood category. They are real issues — missing security headers, permissive CORS configuration, DKIM not configured — but they are not independently exploitable in most cases. A missing X-Frame-Options header enables clickjacking, but a clickjacking attack requires a specific page structure to be effective. A missing Content-Security-Policy does not create an XSS vulnerability by itself, but it means that any XSS vulnerability elsewhere in the app has a higher impact. Medium findings compound with other issues. Fix them after criticals and highs, but do not ignore them — an app with many medium findings is one where a single additional vulnerability can escalate into a significant incident.
Low findings are configuration hygiene items: informational DNS records that could aid reconnaissance, slightly permissive but not immediately dangerous settings, outdated dependency versions without known exploits. They are worth fixing when you have time but should not compete with higher-severity items for your immediate attention. The goal is not a perfect score — the goal is eliminating the findings that create real risk first. A score of 85 with no criticals or highs is a better security posture than a score of 90 that has hidden one critical finding.
The most productive way to use a security score is to re-scan after every significant change and treat each re-scan as a regression test. When you fix a finding, re-scan to confirm the fix actually addressed the root cause — not just the symptom. When you add a new feature, re-scan to check whether the new code introduced new findings. The score trend over time is more informative than any single score: a score that is consistently above 80 and improving with each new feature deployment signals that security is being considered alongside product development, not retrofitted after an incident.