How to Read Your SimplyScan Security Report

Quick answer: A SimplyScan report groups supported findings across security, speed, SEO, AEO, accessibility, compliance signals, domain health, and email configuration. Read severity, evidence, and coverage together. Investigate exposed credentials promptly and test application-specific controls beyond the scan’s reach.

By Daniel A · Kraftwire Software

A SimplyScan report is a prioritized action list for your vibe-coded application.

It provides a security score, categorizes findings across 8 dimensions (security, speed, SEO, AEO, accessibility, compliance, domain, and email), and assigns severity levels from Critical to Low.

Investigate suspected exposed secrets promptly. Revoke credentials confirmed exposed, assess access and injection findings in context, and prioritize fixes by impact, exposure, and your incident-response requirements. A severity label alone does not set a universal remediation deadline.

What Does Your SimplyScan Report Cover?

Your SimplyScan report presents supported findings, scores or category grades, and available recommendations. For developers using Cursor, Windsurf, or Lovable, it supplies evidence to investigate as part of a broader release assessment.

Use this guide to interpret findings and choose follow-up checks. Review generated code and deployed configuration independently of whether visible features work.

How Does the Security Score Work?

The security score runs from 0 to 100 and uses eligible security findings. The other seven dimensions have separate grades. Free reports emphasize findings and partial coverage; the score does not replace reading what was and was not checked.

What the Score Means

The score summarizes deductions from eligible security findings. Deductions can accumulate across medium or low findings, so a low score does not prove that a critical vulnerability exists or that a finding is exploitable. Read the individual findings, their severities, and the scan’s coverage before deciding what to fix.

How the Score Is Calculated

The score applies severity-based deductions and caps for eligible high or critical findings. Category summaries, advisory and coverage findings, and AI-sourced findings do not contribute to this security score. The score is a summary of the recorded findings, not proof that unreported vulnerabilities are absent.

The 8 Dimensions of a SimplyScan Audit

SimplyScan groups supported site checks into the dimensions below. Coverage depends on the inputs and checks completed; no category grade establishes that the entire site is healthy.

1. Security

Supported checks include recognizable exposed-secret formats, selected client-code patterns, response headers, and anonymous backend exposure. A database connection string in a client-side useEffect hook may expose credentials. Review XSS defenses and database permissions directly; a URL scan does not verify signed-in cross-user access.

2. Speed

Checks include selected asset, request, and loading patterns. Where available, CrUX data provides field Core Web Vitals; missing data is a coverage limit. A speed finding is not proof of denial-of-service susceptibility, and the scan is not a load test.

3. SEO

Supported checks inspect metadata, headings, and sitemap-related signals. Review crawler access and rendered content separately where needed. The meta tags generator can draft markup for you to install and test; it does not fix an application automatically or guarantee indexing.

4. AI Visibility (AEO)

Answer Engine Optimization (AEO) checks inspect selected crawler-facing signals, including robots.txt permissions and structured data. They do not observe every engine’s behavior or establish whether ChatGPT or Claude will cite a page.

5. Accessibility (WCAG)

Supported automated checks inspect signals such as text alternatives and accessible names. Use the color contrast checker for selected color pairs, and test keyboard and assistive-technology behavior separately. These checks do not establish WCAG conformance.

6. GDPR & Compliance Signals

Supported checks look for policy-link, tracker, and consent-interface patterns in inspected HTML. They do not execute every consent flow, validate policy contents, or establish legal compliance.

7. Domain Health

Supported checks inspect available registration-expiry and transfer-lock data, nameservers, DNSSEC, and CAA records. The separate SSL Checker inspects supported TLS and certificate signals. Review unavailable data and reported errors.

8. Email Security (SPF/DKIM/DMARC)

The email security tool checks supported DNS records, including selected DKIM selectors and DMARC policy signals. SPF authorizes envelope senders, DKIM validates signed message content, and DMARC evaluates alignment with the visible From domain. DNS checks alone do not prove message authentication or guarantee delivery.

Understanding Severity Levels

Severity helps prioritize investigation. Consider the finding’s category, evidence, affected resources, and coverage alongside its label.

Critical Severity

Treat critical findings as urgent investigation priorities. The label does not prove exploitation occurred.

• Secret patterns: A real exposed credential associated with STRIPE_SECRET_KEY or OPENAI_API_KEY needs prompt revocation; a variable name alone is not a leaked credential.
• Access findings: Confirm whether the response exposes an operation or data intended to be private.

A service_role credential bypasses RLS; its database privileges still determine which operations it can perform. Keep it out of client-side code.

Action: Revoke a credential confirmed exposed, investigate usage, and deploy a replacement through protected server-side configuration. Moving an exposed value into an environment variable does not invalidate existing copies.

High Severity

A high finding warrants prompt investigation, but the label does not establish attack likelihood or that exploitation is harder than for every critical finding.

• RLS configuration: Review table privileges alongside RLS state and policies; disabled RLS does not automatically grant access.
• Code injection: Investigate reported patterns and test whether untrusted input reaches an executable context.

Action: Assess impact and exposure, contain active risks, and assign a remediation owner and deadline appropriate to the application.

Medium Severity

Investigate medium findings in context; combinations of weaknesses can have serious consequences. Examples can concern session cookies, asset loading, or metadata.

• Cookies: Review whether sensitive session cookies need HttpOnly and Secure attributes.
• Assets: Investigate large images and their measured loading impact.
• Metadata: Review missing or incorrect tags and the affected previews or crawler signals.

Action: Schedule remediation according to the affected behavior and risk, and test dependencies between findings.

Low / Informational

Read low-severity findings and informational coverage notes for their specific meaning; they are not interchangeable.

• Framing controls: Review X-Frame-Options and CSP frame-ancestors against your intended embedding policy. Using the former is not automatically a flaw.
• Images: Decorative images generally need empty alternative text; useful images need appropriate alternatives.
• Assets: Investigate reported unused CSS or JS in the relevant runtime context.

Action: Plan relevant improvements and follow up on untested areas. Chasing a perfect score is not a substitute for risk assessment.

How to Read an Individual Finding

Every finding in the SimplyScan report is designed to be actionable for both humans and AI agents (like Cursor or Windsurf).

• Title: A summary of the reported condition.
• Evidence: Available observations supporting the finding; inspect context and possible false positives rather than treating a pattern match as conclusive proof.
• Risk: The potential impact to assess for your application.
• Fix: An available recommendation or code example to review and test before applying. Free reports expose selected details; other fixes require the full report.

Prioritizing Your Fixes: A Step-by-Step Plan

Don't try to fix everything at once. Use the findings’ severity, impact, and coverage to prioritize investigation:

• Secrets: Follow the exposed-key guide. Revoke a real exposed credential and investigate use; deleting it from source is insufficient.
• Authorization: Compare Supabase policies or Firebase Rules with intended access. Test anonymous, authorized, and unauthorized users on resources you control.
• Headers: Review a suitable CSP and framing policy. Settings may live in next.config.js, vercel.json, or another deployment layer. The CSP generator provides a starting point that needs testing.
• Performance and discoverability: Investigate measured asset and crawler findings alongside security work; completing earlier steps does not establish that every security boundary holds.

Why You Must Rescan After Deploying

A report records observations at scan time. Review changes to the deployed code, configuration, and application behavior, then choose checks that cover those changes.

After deploying a fix to a reachable staging or production URL, use an available rescan and inspect its coverage. A free scan has a limited rescan allowance.

• Check whether the previously observed secret pattern is still detected; revoke the credential separately.
• Inspect the relevant response to confirm the intended header is served.
• Compare performance observations under comparable conditions.
• Retest affected accessibility behavior, including checks the scanner cannot perform.

Pro Monitoring includes Pro scan credits for full reports. See pricing for the allowance associated with your chosen option.

Pro Monitoring also provides scheduled rescans and uptime monitoring. Review detected changes alongside the checks and intervals covered; uptime observations do not verify application security.

Key Takeaways for Vibe Coders

Use the report to plan investigation and record remaining gaps. Review the context of sensitive APIs such as dangerouslySetInnerHTML, and verify email authentication separately. Neither a tool’s name nor working features establish that controls are correct.

For Bolt.new, v0, or Replit projects, combine scan findings with code review and application-specific tests. A high score is a summary of covered findings, not evidence of a universally secure foundation.

Run a free scan now to see where your application stands and get your prioritized fix list.

Related Guides

• The Ultimate Vibe Coding Security Checklist
• How to Fix Exposed API Keys in 5 Minutes
• Understanding Supabase RLS Policies
• AEO: How to Rank in AI Search
• Application Security Audit Checklist
• Windsurf Security Risks & Mitigation

Pro Monitoring costs $24/month.