How to check a website for common security issues

Start with what the public site exposes

A live website check is useful when you have a deployed app but have not connected its source code. Founders, developers and site maintainers can use it to spot public-facing configuration problems and accidental exposures. Start with a site you own or are authorized to assess.

Open the website scanner, enter the site's HTTPS URL and start a free live URL scan. You can begin without an account or credit card; guest scans have usage limits. Read the findings before deciding which changes the app needs.

What SetRepo can check from a URL

The live scan looks at the site's public responses and the JavaScript it serves. Its checks include:

• HTTPS and TLS: certificate and HTTPS configuration, including whether HTTP redirects to HTTPS.
• Security headers and cookies: response settings that affect browser protections and cookie handling. A missing header needs interpretation in the context of how the app works.
• Public JavaScript: recognized secret patterns in fetched scripts and exposed source maps. A private API key in a bundle is accessible to visitors even if the original environment file is private.
• DNS and email authentication: infrastructure signals such as SPF and DMARC records. These checks concern domain configuration; they do not test whether a user can access another user's data.

The scanner fetches a bounded set of homepage scripts and referenced chunks. It does not crawl every screen or download an unlimited amount of JavaScript. A key loaded only on another page may be outside that scan's coverage.

When domain verification adds checks

Additional checks for exposed files and publicly readable Supabase or Firebase data require verified domain ownership. Without verification, those checks are skipped, and the report records that limitation.

On a verified domain, SetRepo can check selected exposed-file paths and make limited read requests against supported backend services discovered from the site. A publicly readable table can be intentional, such as a product catalog. A finding should prompt you to confirm what data is meant to be public and whether the access matches that intent.

SetRepo does not use detected secret keys to test access. Public-by-design values, such as a Supabase anon key, Firebase web API key or Stripe publishable key, are not automatically secret exposures. The permissions around the data still matter.

Turn findings into specific fixes

1. Confirm the reported response, bundle or configuration belongs to your current deployment.
2. Prioritize exposed private credentials and unintended access to private data. Revoke and rotate a leaked credential; removing it from JavaScript alone is insufficient.
3. Adjust headers, HTTPS or cookie settings at the server, host or application layer that controls them. Test important pages and sign-in behavior after changing browser restrictions.
4. Publish the fixes through your normal release process and scan the live URL again. A local fix has not changed the public site until it is released.

What needs code or manual testing?

A URL-only scan cannot inspect private server handlers, dependency manifests or database rule files. It does not sign in, try different user roles or prove that an app is secure. For that broader review, connect the GitHub repository and manually test authorization with separate accounts.

Use the website security walkthrough for a review spanning code, deployment and account permissions, and the launch checklist to record evidence before release. The accuracy page lists scanner limitations.

Check your website now to start with its publicly reachable surface.