Methodology
GuardMint Scan Methodology
How GuardMint evaluates public launch-readiness signals, what the results mean, and where a public scan has natural limits.
Short answer
GuardMint runs an automated, public, non-invasive review of a submitted URL. It evaluates visible launch-readiness and security signals, then turns them into a prioritized report. The scan is useful for catching common public mistakes before launch, but it is not a penetration test and cannot prove an app is fully secure.
1. What GuardMint scans
GuardMint scans the public URL or domain you submit. It looks for externally visible launch security and readiness signals — the things any visitor, browser, or search engine could observe — and turns them into a clear, prioritized report.
It's built for founders, vibe coders, small teams, and web app builders who shipped quickly (often with AI builders or no-code tools) and want a sanity check before real users and real data arrive. Start at the free scan.
2. How the public scan works
GuardMint evaluates what is publicly visible from the outside. It does not require credentials, private dashboard access, source-code access, or provider access for the public scan. The goal is to identify obvious public gaps without touching private systems or user accounts.
What the scan never does
GuardMint does not exploit vulnerabilities, brute force, bypass authentication, perform destructive testing, access private systems, or attempt unauthorized access. The public scan is intentionally limited to non-invasive signals.
3. Public scan areas
GuardMint performs automated checks against your app's publicly observable security surface. Every report groups its results into the same 12 security areas below, plus separate launch-readiness checks.
Security areas (12)
These areas make up your security score.
HTTPS / TLS
- What we evaluate
- Confirms your site is served over HTTPS and that plain HTTP visits redirect to it.
- Why it matters
- Without HTTPS, traffic between your users and your app can be read or altered in transit.
- What a public scan can't confirm
- An outside check can't validate every edge of your certificate and proxy configuration.
Exposed files & secrets
- What we evaluate
- Looks for files like .env, .git/config, or Supabase and Firebase config that can be downloaded publicly.
- Why it matters
- A single downloadable config file can hand over database credentials or API keys.
- What a public scan can't confirm
- Only a fixed list of well-known paths is checked, so files at other locations aren't covered.
Frontend JS secrets
- What we evaluate
- Scans your public HTML and JavaScript bundles for private credentials, such as secret API keys or service-role tokens.
- Why it matters
- Anything shipped to the browser is readable by every visitor, including private keys bundled by mistake.
- What a public scan can't confirm
- Secrets that live only on your server or in a private repository aren't visible to a public scan.
Source maps
- What we evaluate
- Flags production source maps that make your original source code readable to anyone.
- Why it matters
- Readable source makes it far easier to find weaknesses and hard-coded values in your app.
- What a public scan can't confirm
- Only source maps referenced from the scanned frontend assets are checked.
Supabase exposure
- What we evaluate
- When a Supabase project and anon key are found, checks whether a few common tables return rows without authentication.
- Why it matters
- Tables without Row Level Security can be read by anyone holding the public anon key.
- What a public scan can't confirm
- A clean result doesn't prove every table has correct Row Level Security; only a short list of common tables is tried.
CORS
- What we evaluate
- Flags API responses that let any other website read your data cross-origin.
- Why it matters
- A permissive CORS policy lets another site read your API responses in a visitor's browser.
- What a public scan can't confirm
- Only the API paths the scan probes are checked, not every endpoint in your app.
Cookies & sessions
- What we evaluate
- Checks session cookies for missing Secure, HttpOnly, and SameSite protections.
- Why it matters
- Unprotected session cookies are easier to steal or ride along with in cross-site requests.
- What a public scan can't confirm
- Cookies set only after sign-in aren't visible to a public scan.
Public API data exposure
- What we evaluate
- Checks common API paths for JSON responses that return personal, payment, or admin fields without a login.
- Why it matters
- An API route missing an auth check can leak user or business data to anyone who finds it.
- What a public scan can't confirm
- Only common API paths are probed without logging in; authorization between signed-in users can't be tested.
Error & debug leakage
- What we evaluate
- Looks for stack traces, framework or database errors, and debug output in public responses.
- Why it matters
- Detailed errors reveal internals such as file paths, queries, and library versions.
- What a public scan can't confirm
- Errors that only occur behind a login or with specific input aren't triggered by the scan.
Security headers
- What we evaluate
- Reviews browser protections such as Content-Security-Policy, HSTS, clickjacking, and MIME-sniffing headers.
- Why it matters
- These headers limit common client-side attacks and are easy to leave off by default.
- What a public scan can't confirm
- A header being present doesn't prove it's complete or applied correctly across every page of the app.
Route exposure
- What we evaluate
- Checks common admin and API-documentation paths for interfaces that load without a login.
- Why it matters
- Admin panels and API docs left open give outsiders a map of, or a way into, your app.
- What a public scan can't confirm
- Only common paths are checked, and a page loading doesn't show whether the actions behind it are enforced.
Open ports & infrastructure
- What we evaluate
- Checks a short, fixed list of common ports for publicly reachable databases, caches, or dev servers.
- Why it matters
- A database or dev server reachable from the internet is a direct path to your data.
- What a public scan can't confirm
- Only a fixed list of common ports is checked; this is not a full port or network scan.
Launch-readiness checks (2)
These are practical launch blockers, not vulnerabilities. They are reported separately and do not lower your security score.
Domain & email (DNS)
- What we evaluate
- Reads your domain's public email records, such as SPF and DMARC.
- Why it matters
- Missing email records make it easier for others to send mail that impersonates your domain.
- What a public scan can't confirm
- Public records don't show whether your email provider actually enforces them.
Legal & trust pages
- What we evaluate
- Checks that privacy policy, terms, and contact pages are reachable.
- Why it matters
- App stores, payment providers, and users expect these pages before they trust a product.
- What a public scan can't confirm
- This confirms the pages exist, not that their content meets any legal requirement.
4. Finding states
Findings are grouped by severity and coverage. Severity helps prioritize visible issues; coverage states explain whether the public scan had enough context to judge the area confidently.
- Critical
- A serious, externally visible issue that should be addressed before launch.
- High
- An important issue with meaningful risk that should be fixed soon.
- Medium
- A moderate issue worth reviewing and resolving before you scale up traffic.
- Low
- A minor issue or hardening opportunity with limited immediate risk.
- Info
- A neutral observation for context. It is not a problem to fix on its own.
- Passed
- We checked this area from the outside and saw no issue in what was publicly observable.
- Not fully checked
- We could not confidently verify this area from an unauthenticated public scan.
“Not fully checked” is not a pass or a failure
It means the area cannot be confidently verified from an unauthenticated public scan. Treat it as “we couldn't see enough to judge,” not as “everything is fine” or “something is broken.”
5. How GuardMint scoring works
The score is designed to summarize launch-readiness, not to expose a formula or certify security. It helps teams decide what to fix first.
Scores run from 0 to 99, where higher is better. GuardMint never awards 100 — no automated, unauthenticated scan can certify perfect security, so 99 is the best possible external result. Resolving a finding and re-running the scan should improve the score where that issue affected it.
- Higher-severity findings are treated as more urgent than minor hardening suggestions.
- Passed checks are positive signals, but they do not prove the app is secure.
- Informational and not-fully-checked items are separated from confirmed issues so users can interpret them correctly.
- The score is a practical launch-readiness indicator, not a security guarantee or compliance grade.
6. What a public scan can confirm
From the outside, a public scan can generally confirm things like:
- Whether important browser-facing protections are visible on public responses.
- Whether obvious exposure patterns appear publicly reachable.
- Whether the public site presents a secure and consistent entry point.
- Whether visible responses contain risky launch signals that deserve review.
7. What a public scan cannot fully verify
Some important risks sit behind logins, inside private repositories, or inside provider dashboards. A public scan cannot fully verify those areas.
- Whether authentication and account flows are implemented correctly.
- Whether authorization or Supabase RLS is correctly enforced for every user and role.
- Whether domain and email-security settings are complete and enforced across providers.
- Whether secrets exist inside a private repository or private deployment environment.
- Whether payment, admin, or user flows are secure behind login.
- Whether third-party providers are configured securely.
- Whether the app complies with any legal, regulatory, or security framework.
For deeper coverage of these areas, our guides go deeper: the pre-launch security checklist, accidentally exposed secrets, and the Supabase RLS checklist.
For the full limits of a public scan, see the security scan disclaimer.
8. Why some areas need more context
Some checks require more context than a public scan can fairly or reliably use. For example, deeper domain, repository, provider, or authenticated-flow review should only happen when the requester can prove they control the relevant asset.
In the future, GuardMint may support verified-owner workflows for deeper checks. Those workflows would be separate from the current public URL scan and would require explicit authorization.
If you own a domain and want it excluded from scans or public report display today, see the domain opt-out page.
9. Future methodology
GuardMint may add deeper scan modes over time. These are possible future directions, not current public-scan features:
- Verified-owner checks for confirmed domains.
- Opt-in repository review for authorized users.
- Framework-aware configuration review.
- Deeper domain and provider-level analysis.
- Private reports for verified owners.
10. FAQ
- Is GuardMint a penetration test?
- No. GuardMint is an automated, public, non-invasive scan. It does not exploit vulnerabilities, bypass authentication, or perform the manual, authorized testing that defines a penetration test. It is a launch-readiness signal, not a substitute for a professional security assessment.
- Can GuardMint prove my app is secure?
- No. GuardMint can surface common, externally visible issues, but no automated public scan can prove an app is fully secure. Passed checks are useful signals, not guarantees. Critical or unclear findings should be reviewed before launch.
- Why are some checks marked Not fully checked?
- "Not fully checked" is not a pass or a failure. It means GuardMint could not see enough from the public surface to judge the area confidently. This usually applies to areas that need ownership verification, authenticated access, source-code context, or provider-level configuration.
- Does GuardMint attack or exploit my website?
- No. GuardMint is intentionally non-invasive. It does not exploit vulnerabilities, brute force, bypass authentication, run destructive tests, or attempt unauthorized access.
- Should I scan only domains I own?
- You should scan domains you own or are authorized to test. Scanning is non-invasive, but you're responsible for having permission. Domain owners can request exclusion on the domain opt-out page.
- Will GitHub scanning be different from public URL scanning?
- Yes. Public URL scanning and repository review are different scan modes. If GuardMint adds GitHub scanning, it should be explicit, opt-in, and based on authorized repository access rather than public web responses alone.
See where your app stands
Run a free public scan and get a prioritized launch-readiness report without giving GuardMint private access.