How to check if your website is secure

Start with the website and the code behind it

A website can load correctly, use HTTPS, and still expose customer records through an API. Checking security means looking at several layers: what visitors can see, what the server accepts, and which data each user can access.

This walkthrough is for people checking a website they own or are authorized to test. Use staging and disposable accounts for tests that change data. Keep a note of the URL, deployment version, date, and what you tested so you can repeat the same checks after a fix.

For a first pass, open the free website security scanner. If you are preparing to ship, use the website security checklist to track the remaining work.

1. Check HTTPS and the responses your site sends

Open your site in a fresh browser window. Confirm that the intended domain loads over HTTPS without a certificate warning. Check that an HTTP visit redirects to HTTPS, and that pages do not load scripts or other active resources over an insecure connection.

In your browser's developer tools, open Network, reload the page, and inspect the main document's response headers. You can also inspect the headers from your own domain with:

1curl -I https://yourapp.example

Look for a Content-Security-Policy that fits your app, protection against unwanted framing, and an appropriate Strict-Transport-Security policy once HTTPS is working consistently. Inspect login and API responses too; different routes can send different headers. A missing header deserves investigation, while its presence alone does not establish that the policy is effective.

For example, a Content-Security-Policy finding should lead to a policy designed around your scripts, styles and trusted services. Test it in report-only mode before enforcing a policy that could break checkout or sign-in. MDN's CSP reference explains the directives and deployment options.

2. Look for secrets in what reaches the browser

Inspect your production JavaScript and the environment variables bundled into it. Private API keys, database passwords and Supabase service-role credentials belong on the server. Variables with prefixes such as NEXT_PUBLIC_ or VITE_ can be included in browser code.

Some identifiers are intentionally public: a Supabase publishable or legacy anon key, for example, needs correctly configured database access policies. Identify the key's purpose before treating every visible value as a leak.

If a private credential has been exposed, revoke or rotate it, remove it from browser code, and deploy the change. Deleting the string from the latest file does not invalidate a key that someone already copied. Review relevant provider logs and repository history as part of the response. See the exposed secrets guide for the follow-up steps.

3. Test access with two ordinary accounts

Create test accounts A and B. Give each account its own disposable records, such as a draft project or test order. As A, use the app normally and identify the request that reads A's record. Then use B's session to request that same test record.

The server should deny access or omit the record according to your product's rules. Repeat for updates, deletes, downloads and invitations. Test signed-out access separately. A hidden button or an unlinked admin page does not stop someone from sending the request directly.

For admin operations, verify that an ordinary account cannot perform the action even when it knows the endpoint. These checks help uncover IDOR and missing admin authorization. SetRepo does not sign into your app and perform this two-account test; you need to run it yourself or arrange a security review.

4. Review database and storage permissions

Check the deployed rules as well as the files in your repository. For Supabase, review RLS on exposed tables and the policies for each operation. For Firebase, inspect the rules for the database and storage products your app uses. Make sure private files are protected by storage permissions too.

Test the intended behavior as a signed-out visitor, the record's owner, and a different signed-in user. Require an explicit product reason for public access. A rule that accepts any signed-in user may be too broad for private customer records.

Use the database security guide for the broader review, or the Supabase RLS walkthrough for table-level checks. The providers' own references cover Supabase RLS and insecure Firebase rules.

5. Scan the source and review sensitive flows

Connect your repository or provide a code export to examine things a public URL cannot reveal: backend routes, dependency manifests, configuration and database migration files. Review any scanner finding against the affected code and the deployed version before deciding what to change.

Pay special attention to sign-in, password reset, payments, webhooks and uploads. For example, the server should determine an order's price from trusted product data rather than accepting the browser's total. A payment webhook should verify the provider's signature and handle repeated events safely.

A SetRepo Quick scan runs deterministic checks. A paid Deep scan adds AI review of selected access-control and business-logic code. Neither replaces testing the running workflows. The coverage page lists limitations, and the AI code security guide covers patterns worth reviewing in generated code.

6. Fix, deploy and repeat the same checks

Start with confirmed exposures that could disclose secrets, reveal private data or allow unauthorized changes. Record the evidence, affected component, fix and retest result. For a leaked key, include confirmation that the old credential has been revoked. For an access-control bug, repeat the original test with both accounts after deployment.

Run another scan against the updated site or code, and check that the intended behavior still works for legitimate users. Keep unresolved findings and skipped checks visible. Repeat the review when authentication, permissions, payments or major dependencies change.

For a deeper testing plan, use the OWASP Web Security Testing Guide. The launch checklist turns the steps above into concrete conditions you can record before release.

FAQ

How can I check my website security for free?

Start with a free live URL scan, inspect HTTPS and response headers, and review what your public JavaScript contains. Then use two test accounts to check private-data access. SetRepo offers a free URL scan and free deterministic code scans; guest scans have usage limits. See the pricing and accuracy pages for coverage.

Does HTTPS mean my website is secure?

HTTPS protects the connection between a browser and the server. It does not establish that the server checks permissions correctly, that database rules protect private records, or that your browser code contains no secrets. Review those layers separately.

Can a website scanner find every vulnerability?

No. A scanner reports the issues its checks can identify with the access and inputs it receives. A public URL scan cannot inspect private backend source or exercise every signed-in workflow. Combine scan results with code review and manual testing.

What if I built my website with an AI coding tool?

Use the same checks. Pay particular attention to secrets in public variables, routes without authorization and database rules created during development. The Lovable, Cursor, Replit and Base44 guides describe checks relevant to those workflows.