Key Takeaways
- AI can help interpret security evidence, but a website URL alone cannot reveal private code, database permissions or hosting settings.
- Use staging, sanitized files and two-account tests to check authentication, authorization, credentials and configuration safely.
- Verify every fix and seek professional help for sensitive data, complex permissions, compromise signs or findings you cannot investigate.
Can ChatGPT, Claude or Gemini Check Your Website’s Security? Here’s How
Your AI-built website looks ready for business.
The buttons work. The mobile layout looks sharp. Your friend says it looks “surprisingly professional,” which you decide to accept as a compliment.
Then someone asks:
“Can one customer see another customer’s orders?”
You haven’t tested that.
You tested whether the logo got bigger when you hovered over it.
This is where building a website becomes owning one. A working checkout is encouraging. Knowing who can access the orders behind it is rather more important.
ChatGPT, Claude and Gemini can help you investigate—with free diagnostic tools, relevant code and a few focused prompts.
Let’s follow Maya, the fictional owner of Maple & Mug, as she checks her new online shop before inviting customers in.
Can AI Check Security From Just a Website Link?
Only to a limited extent.
If an assistant has browsing tools, a URL may let it inspect parts of your public website. It doesn’t automatically reveal the private code, database permissions or hosting settings behind it.
Think of it as inspecting a shop window. You might notice a cracked pane. You cannot tell whether the filing cabinet upstairs is unlocked.
For a useful review, give AI evidence: scan results, relevant source files and configuration details.
If you’re still figuring out what needs checking before launch, start with You Built a Website With AI, But Is It Secure? 20 Things to Check Before You Share It. Then use the prompts below to investigate your findings.
Before starting, save a backup. Test potentially disruptive changes on a staging site, a separate test copy of your website. Remove customer information and secret credentials before sharing files with an AI service.
Only assess websites you own or have permission to test.
1. Start With a Free Website Check
Maya begins with the parts of Maple & Mug that public diagnostic tools can inspect.
| Tool | What it helps check |
|---|---|
| Mozilla HTTP Observatory | Security headers: instructions that help browsers handle your site safely |
| Qualys SSL Labs | Your HTTPS certificate and encrypted connection settings |
| SecurityHeaders.com | Missing or weak security headers |
| Google Safe Browsing | Whether Google has flagged your website as unsafe |
Check each service’s current testing limits and report visibility before submitting your site.
Maya’s results flag a missing Content Security Policy, or CSP. This tells browsers which sources of scripts and other content your site permits.
Her first thought: “Have I been hacked?”
The scan hasn’t established that. It has identified a protection worth investigating.
Copy this prompt:
Explain these website security scan results for a beginner.
For each finding:
- Explain what it means.
- Distinguish a vulnerability from a missing protection.
- Recommend the next investigation or fix.
- Explain what the fix could break.
- Show how to verify the result.
Prioritize the findings and identify missing information.
Hosting platform: [PLATFORM]
Sanitized results: [RESULTS]
You want a clear next action. A scanner grade alone cannot tell you whether customer records are protected.
2. Review What Happens Behind the Buttons
Maple & Mug’s contact form looks reassuringly ordinary: name, email, message, Send.
Unfortunately, a tidy form tells Maya very little about what happens to the message afterward.
Does the server check the submitted information? Does the code handle it safely? Do error messages reveal private details?
Those questions require the relevant code.
Look in your project folder, connected GitHub repository or website builder’s code export. Start with files handling forms, logins, customer records and admin actions.
If you cannot identify them, ask your coding assistant to locate and explain them first.
Copy this prompt:
Review this sanitized website code for security weaknesses.
Focus on unsafe input handling, authentication, permissions,
sessions and sensitive information in error messages.
For each finding:
- Point to the exact code.
- Explain a realistic misuse scenario in plain English.
- State the evidence and what remains uncertain.
- Suggest a minimal fix and a verification test.
Ask for related files when necessary.
Code and context: [PASTE HERE]
Treat a finding as something to investigate. An assistant reviewing one file may be missing protections—or problems—in another.
3. Check Whether You Left a Secret in Public
Your site may use credentials to connect to an email service, database or payment provider.
Some keys are intended to appear in public code with suitable restrictions. Others grant private privileges.
The word “key” alone doesn’t tell you which kind you have. What it allows someone to do is what matters.
Review your repository’s available secret-scanning alerts, public code and project settings. Look closely at private keys, admin credentials and powerful database credentials.
Copy this prompt:
Review how this project handles credentials.
All actual secret values have been removed.
Identify credentials that could reach public code, files,
repository history or logs.
Explain:
- Which keys are intentionally public.
- Which credentials must remain private.
- How to verify suspected exposure.
- What to revoke or rotate if exposure occurred.
- How to prevent it happening again.
Redacted configuration and project structure: [PASTE HERE]
If a private credential was exposed, revoke or rotate it. Removing it from the latest file does not erase earlier copies.
And resist the temptation to paste a password into chat with the question, “Is this safe?”
That creates a second problem while investigating the first.
4. Try the Two-Customer Test
This is the question that interrupted Maya’s victory lap.
She creates two accounts and some pretend orders on her staging site:
- Customer A owns an order.
- Customer B should have no access to it.
Now she asks her coding assistant to help test whether B could retrieve A’s order by changing the order identifier in a request.
In our fictional example, the test exposes a flaw: the page hides other customers’ orders, but the server doesn’t check ownership before returning an order.
The shop window looks private. The filing cabinet is open.
Copy this prompt:
Review my login code, server request handlers and database
access rules.
Using two accounts and test records I control in staging,
help me check whether:
- Customer B can retrieve Customer A's records.
- A regular user can perform an admin action.
- A logged-out visitor can access protected information.
For each test, provide the action, expected result and
evidence to inspect. Suggest fixes for supported findings.
Sanitized code and access rules: [PASTE HERE]
Two terms help here:
Authentication: Who are you?
Authorization: Are you allowed to access this particular thing?
Maya’s customers can log in correctly. Her server also needs to check which orders belong to them.
After fixing that check, she repeats the test. Customer A can retrieve the order. Customer B is denied.
That is a useful result: a specific problem, a specific correction and evidence that the correction works.
5. Check the Settings Before Tightening Everything
Security settings can help protect your website. They can also break parts of it when applied incorrectly.
Maya returns to her missing Content Security Policy. A proposed policy looks impressively strict—until she tests it and her payment widget disappears.
A checkout that accepts no payments is certainly a business model. It is unlikely to be hers.
Hosting settings deserve the same care as code changes.
Copy this prompt:
Review this sanitized hosting configuration.
Check HTTPS, security headers, cookie settings, public file
access, debug mode and error messages.
Also review CORS: rules controlling which other websites
can make certain browser requests to my server.
For each concern:
- Explain the practical risk.
- Separate urgent findings from optional improvements.
- Describe possible breakage.
- Provide staging tests.
- Identify guidance to confirm in official platform docs.
Platform and configuration: [PASTE HERE]
Make manageable changes and check the affected features. For Maya, that means testing checkout before declaring her new policy a success.
6. Inspect the Software You Borrowed
Most websites contain code their owners never wrote.
These dependencies include packages, plugins and themes. A problem in one can affect the site using it.
For JavaScript projects, a common starting point is:
npm audit
GitHub Dependabot can provide dependency alerts where available. WordPress owners should check installed plugin and theme versions against relevant security advisories.
A report full of warnings can feel like a dashboard lighting up during a road trip. You need to know which warning requires stopping and which needs further investigation.
Copy this prompt:
Explain this dependency security report for a beginner.
For each finding:
- Identify the affected package and versions.
- Explain the conditions needed for exploitation.
- Assess exposure using the project context provided.
- Recommend a supported fix.
- Explain what to test after updating.
Flag uncertainty and missing information.
Do not invent current vulnerability details.
Report and project context: [PASTE HERE]
Review proposed upgrades before approving them. Clearing a warning is useful; keeping login and checkout working is also part of the job.
7. Ask for Priorities Before You Disappear Into Reports
Maya now has scan results, code findings and package warnings.
She could spend the evening organizing them by colour. She needs to organize them by consequence.
Copy this prompt:
Turn these findings into a prioritized security action plan.
Separate:
1. Confirmed vulnerabilities.
2. Suspected problems needing verification.
3. Configuration improvements.
4. Important areas not yet tested.
For each item, include evidence, potential impact,
recommended action and verification steps.
Group actions into urgent, next seven days and ongoing.
Explain the reason for each priority.
Do not invent results or declare the website fully secure.
Sanitized findings: [PASTE HERE]
A useful plan makes the next action obvious. It also records what you have not checked.
ChatGPT, Claude or Gemini: Which Should You Choose?
Choose an assistant that can work with your project’s files and explain its reasoning clearly. Available capabilities depend on the model, tools and account.
Give it one relevant file and one scan result. Look for:
- Specific evidence supporting each finding.
- Questions about missing context.
- Clear explanations of uncertainty.
- Tests you can use to verify a fix.
If two assistants disagree, investigate the evidence. Three confident answers do not constitute a security certificate.
When Should You Bring in an Expert?
Consider professional help if your website handles sensitive information, has complex access permissions, shows signs of compromise, or produces findings you cannot confidently investigate.
AI reviews can miss serious weaknesses, particularly those involving several systems or unusual application behaviour. They can also suggest incorrect changes.
Bring your reports and test results to the reviewer. Knowing what you checked—and what remains uncertain—makes the conversation more useful.
Before You Invite Customers In
Check that you have:
- Run public diagnostic checks.
- Reviewed important code and credentials.
- Tested access with two separate accounts.
- Checked hosting settings and dependencies.
- Verified fixes and recorded untested areas.
These steps give you a more informed starting point. They do not prove your website is free from vulnerabilities.
Maya still checks the mobile layout before launching Maple & Mug.
But now she also knows that Customer B cannot retrieve Customer A’s test order—and that her stricter browser policy still lets customers pay.
The hover animation survives too.
It has simply moved down the priority list.