Find security gaps in your website, understand the evidence, and take a focused repair brief back to your AI coding tool. Recheck after deployment to see what changed.
Opens an email to hello@securityfuse.com.
Checks public website settings, not signed-in pages. Every scan needs your confirmation that you are authorized; Deep also needs domain ownership proof. Scope and requirements
Original scan ·
No Content Security Policy header observed on the homepage
Low severityRecorded evidence
No Content-Security-Policy header was returnedFix
Locate the HTML response header configuration and define a Content-Security-Policy suited to the application.
View repair briefRecheck of the same test site ·
This finding: No longer observed
A controlled test on our own site with the same checked settings, not a production deployment. It covers this finding only, not the whole site.
View recheck resultThis example checked 2 security headers on the test site’s homepage. TLS, DNS and other areas were not part of it. Full sample scope
Recorded on our own owner-authorized test site, shown under a fictional alias. Not customer data.
Both recorded findings, the repair brief and the scoped recheck result.
| Finding on the homepage | Severity | Original scan | Recheck of this finding |
|---|---|---|---|
| Missing Content Security Policy header | SeverityLow | Original scanFinding observed | Recheck of this findingFinding no longer observed |
Recorded evidence: Missing Content Security Policy header
| |||
| Missing Strict-Transport-Security header | SeverityLow | Original scanFinding observed | Recheck of this findingFinding no longer observed |
Recorded evidence: Missing Strict-Transport-Security header
| |||
From a recorded recheck of our own test site, with the same settings
The recheck no longer observed these findings. This does not establish suitable header values or overall site safety.
A scoped review instruction, not settings to apply blindly.
/ should send a Content-Security-Policy and a Strict-Transport-Security header, then choose values that fit your site’s scripts and HTTPS setup.Illustrative brief based on the recorded guidance, not an exact exported prompt. You stay in control. No tool or deployment is launched.
Checked: 2 security headers on the test site’s homepage (HTTP responses). Not part of this sample: TLS, DNS and email, public exposure, signed-in pages and the other areas listed below. 1 of 7 areas assessed.
Exported Quick scan and recheck of our own owner-authorized test site, shown under a fictional alias. Not customer data.
A controlled test with synthetic HTTP transport standing in for HTTPS headers. The recheck is not a production deployment.
3 of 3 scheduled configuration settings assessed. The sample has 2 completed weighted header checks. Earlier: 0 passed; recheck: 2 passed. A numeric score requires at least 5 completed weighted checks.
Request target: https://demo.example/
Content-Security-Policy: not returned
Finding ID: 4af59a3b7f93732e570d9456
Recheck: No longer observed
Strict-Transport-Security: not returned
Finding ID: 69345dca363b732777d97c71
Recheck: No longer observedThe owned fixture uses synthetic HTTP transport to represent HTTPS headers. The report pair was exported through the shared report contracts, then aliased and identity-redacted for this static presentation. The repair handoff illustrates the recorded guidance; it is not an exact exported brief. Missing headers alone do not establish exploitability. Intended access and application behavior were not tested. No overall safety claim is implied.
Access is by invitation. Request beta access, then create your account once your invitation is confirmed.
Choose Quick or Deep and confirm that you are authorized to assess the site. Deep also needs domain ownership proof.
Read what was observed, why it matters and what was not assessed.
Take a scoped brief to your coding tool. Review, test and deploy the change yourself.
After your deployment, run a comparable recheck with the same settings.
In your own workflow, the recheck follows your real deployment. The sample above is a controlled test on our own site.
Evidence, within an authorized scope.
Invitation beta
Understand the configuration gaps that need your attention.
| Profile | Quick | Deep adds |
|---|---|---|
| Needs | Your attestation | Everything in Quick, plus ownership proof |
| Covers |
|
|
Not in the hosted beta yet
Bring concrete evidence from a pinned snapshot into your repair discussion.
Not included: code execution or complete source-code coverage.
Act on what was observed, not on a guess.
See what was recorded before deciding what to change.
What wasn’t checked is labelled, and never shown as safe.
A repair statement isn’t verification. Recheck with the same settings to see what is still observed, what changed and what remains uncertain.
Not live yet. Listed so you can tell us whether they matter to you.
Planned
Application reviews connect the builder, business owner and reviewer around the intended use, recorded evidence and accountable human decisions.
A recheck does not approve an application. The decision stays with a person.
Interested for your team? Tell usBuilding with MCP servers and coding agents? We plan to add static checks for tool permissions, exposed secrets and risky configuration.
Find website security gaps, prepare a focused repair brief, and recheck after deployment.
Opens an email to hello@securityfuse.com.