Understand the findings.
Explore 23 topics, from secure transport and browser protections to application risks that need a separate review.
Some topics need a source-code review or scoped testing. Related public checks provide context; they do not establish full coverage of a vulnerability class.
Transport & browser
Connections, browser policies and the boundaries between origins.
- HTTPS & secure transport
- HTTPS protects data in transit between a browser and a server. It does not establish that an application’s private logic is secure.
- TLS configuration
- Certificates and supported protocol versions describe aspects of transport protection. They do not cover application authorization or stored data.
- HTTP Strict Transport Security
- HSTS tells supporting browsers to use HTTPS for a host within the policy’s lifetime. Changes need to account for the site and its subdomains.
- Content Security Policy
- A browser policy can restrict resource loading and script execution. Its effect depends on the actual directives and how the website uses them.
- Security response headers
- Headers configure browser protections and information-sharing behavior. They are useful defense-in-depth signals rather than a complete security assessment.
- Clickjacking protection
- Framing protections help control which pages may embed a website. Review them alongside the actions available on sensitive pages.
- Cross-Origin Resource Sharing
- CORS controls when browsers can expose responses to another origin. Its significance depends on the data, credentials and origins involved.
- Cookie security
- Secure, HttpOnly and SameSite attributes affect browser handling of cookies. The relevant requirements depend on the cookie’s purpose and the application.
- Referrer Policy
- Referrer-Policy influences how much referring-page information browsers send with requests. Choose a policy consistent with the site’s privacy and functional needs.
Public exposure
Information and software signals visible from outside a website.
- Information disclosure
- Public responses may reveal implementation details or sensitive material. The impact depends on what is actually exposed and how it can be used.
- Exposed environment files
- A publicly readable environment file may expose private configuration. Findings should be verified from the captured response, with secret values kept private.
- Exposed Git metadata
- Repository metadata served from a public web directory may disclose development information. The scanner checks supported public paths and records the observed response.
- Directory listing
- A server-generated file index can reveal files that were not intended to be discoverable. Review the actual listed content and intended public access.
- Outdated dependencies
- Known library and runtime versions can provide useful security signals. Missing or blocked scripts limit what can be identified.
Application risks
Application behavior that needs context beyond a public observation.
- Cross-site scripting
- XSS involves untrusted content executing as script in a page. Public headers provide useful context but cannot prove the absence of XSS in application code.
- Administrative interfaces
- An accessible login page is not by itself a vulnerability. Authorization, authentication and permitted access need a separately scoped review.
- Rate limiting
- Rate controls bound repeated actions and resource use. Evaluating application-specific limits needs agreed scope; the passive scan does not stress-test them.
- SQL injection
- SQL injection concerns untrusted input affecting database queries. The current public review does not submit injection payloads or inspect private database code.
- Open redirects
- Redirect handling can be abused when an application accepts an unintended destination. The passive review does not test arbitrary application redirect parameters.
Email & domain
Sender policies, signatures and their limits.
- Email & domain security
- DNS policies help describe authorized senders and treatment of messages. Website scanning does not prove that every message is authenticated or encrypted.
- Sender Policy Framework
- SPF publishes a domain’s sender authorization policy in DNS. It is one part of email authentication and needs to match the actual sending services.
- DKIM
- DKIM lets receiving mail systems verify signatures associated with a sending domain. A public website review cannot verify every sender’s signing configuration.
- DMARC
- DMARC publishes alignment and handling policies for domain-based email authentication. A policy observation is not proof that all messages are protected.
Keep the scope visible.
Read the exact public check catalog or start a website review with its evidence and limits.
See the check catalog Check a website