GuardMint Scan Methodology

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.

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.

The public scan groups findings into practical areas. The descriptions below explain the kinds of signals GuardMint evaluates without turning the methodology into an implementation manual.

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.

The score is designed to summarize launch-readiness, not to expose a formula or certify security. It helps teams decide what to fix first.

• 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.

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.

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.

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.

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.

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.