Sample summary
The site shows a mostly reachable HTTPS posture, but missing or weak browser security headers should be prioritized before lower-confidence exposure clues.
Sample report
Website risk example report for headers, TLS, cookies and CORS.
This sample shows how OsintNET can organize passive website security findings into an evidence-ready report for owners, analysts and authorized defensive review.
Designed for analysts who need clear signals, not scattered tabs.
Findings format
Each finding should include severity, category, evidence, explanation and a practical fix so owners can act without guessing.
Recommended next steps
Add or tune CSP, HSTS and clickjacking protections, review cookie flags, confirm CORS policy, publish security.txt and validate SPF/DMARC posture.
Common questions
What should a passive website risk report include?
It should include HTTP security headers, HTTPS and TLS posture, cookie flags, CORS exposure, DNS mail-security records, public exposure clues, severity and remediation context.
Is this an active penetration test report?
No. This is a passive public-posture report format for websites you own or are authorized to review.
Continue with the next evidence layer.
Passive website security scanner
Learn which passive web posture checks are included.
OsintNET vs security headers scanners
Compare header-only scanning with broader public posture review.
Domain intelligence example report
Connect website findings back to DNS, SSL, ASN and mail-security context.
Start investigation
Use OsintNET to convert public signals into structured evidence.
Pick the module that matches your target and keep each clue connected to its source, confidence and investigation context.