Methodology
What we test, and how we grade it
A public assessment looks only at what any visitor's browser or mail server can see. Deterministic checks decide every finding and the grade. AI may help explain findings, but it never invents them.
Scope & safety
Passive and bounded
At most 60 requests to the target per assessment, typically 15–25: the homepage over HTTPS and HTTP, /.well-known/security.txt, up to 8 of the scripts the homepage already loads, up to 3 source maps, DNS lookups, and two TLS handshake probes that never complete. Contract lookups go to the public Sourcify registry, never the target.
No exploitation
We never send attack payloads, guess credentials, fuzz parameters, crawl, or attempt to bypass access controls. X mentions never authorize intrusive testing.
SSRF and rebinding defences
Targets must be public domain names. Every hostname, including each redirect hop, is resolved first and refused if any address is private, loopback, link-local, carrier-grade NAT or reserved.
Strict limits
8-second request timeouts, at most 5 redirects, a 1 MB body cap, standard ports only, per-client and global rate limits, and de-duplication of repeat requests for the same domain.
Identifiable
Requests carry the user agent PentestAgentBot with a link to this page, so owners can recognise and filter our traffic.
How grades work
Every site starts at 100. Each issue deducts points by severity. Potential findings (heuristic signals that need owner review) deduct half. Checks that could not run are excluded and listed in the report's limitations.
Deductions
- high−30
- medium−10
- low−4
- info−0
Grade thresholds
- A+≥ 95
- A≥ 88
- B≥ 75
- C≥ 60
- D≥ 45
- F≥ 0
A+ also requires no medium or high issues.
Grade caps
- Max F when https is not working.
- Max B when deprecated tls versions are accepted.
Checks
TLS & transport
Requests the homepage over HTTPS. The request only succeeds if the server presents a certificate that is valid, trusted and matches the domain.
Without working HTTPS, anyone on the network path can read or modify the page — including swapping wallet addresses or injecting scripts.
Requests the homepage over plain HTTP and checks that the first response redirects to HTTPS.
Visitors who type the bare domain arrive over HTTP first. If that page is served instead of redirected, the first hop can be intercepted.
Reads the Strict-Transport-Security header on the HTTPS response and checks max-age is at least 180 days.
HSTS tells browsers to never load the site over HTTP again, closing the downgrade window that the redirect alone leaves open.
Opens a TLS handshake offering only TLS 1.0, then only TLS 1.1, and records whether the server agrees. No application data is sent.
TLS 1.0 and 1.1 are deprecated (RFC 8996) and lack modern protections. Supporting them weakens the connection for clients that can be downgraded.
HTTP security headers
Reads the Content-Security-Policy header and flags policies that still allow inline or arbitrary-origin scripts.
CSP limits which scripts can run. For dApps it is the main browser-side defence against an injected script draining connected wallets.
Checks for X-Frame-Options or a CSP frame-ancestors directive.
Without framing protection, another site can embed this one invisibly and trick users into clicking — for example approving a transaction.
Checks that X-Content-Type-Options is set to nosniff.
Stops browsers from interpreting uploaded or mislabelled files as scripts or stylesheets.
Reads the Referrer-Policy header and flags policies that leak full URLs to other sites.
URLs can contain tokens, wallet addresses or referral codes. A strict policy keeps them from leaking to third parties.
Checks for a Permissions-Policy header restricting powerful browser features.
Limits what embedded third-party content can access, such as camera, microphone or payment APIs.
Looks for exact software versions in the Server, X-Powered-By and similar headers.
Exact versions make it easier to match the server against known vulnerabilities. This is a signal, not a vulnerability by itself.
Cookie configuration
Inspects every cookie set while loading the homepage and checks it carries the Secure attribute.
Cookies without Secure can be sent over plain HTTP, where they can be read on the network.
Checks that cookies whose names suggest a session or auth token carry HttpOnly.
HttpOnly keeps session cookies out of reach of JavaScript, so a script injection can't steal the session.
Checks that cookies declare a SameSite attribute.
SameSite limits when cookies are sent on cross-site requests, which reduces cross-site request forgery risk.
DNS & email posture
Resolves the domain through a validating resolver and checks whether the answer is DNSSEC-authenticated.
DNSSEC prevents forged DNS answers from sending visitors to a look-alike server.
Looks up CAA records for the domain and its parents.
CAA restricts which certificate authorities may issue certificates for the domain, reducing the risk of a mis-issued certificate.
Reads the domain's TXT records for an SPF policy and checks it is not permissive.
SPF lists who may send mail as the domain. Crypto projects are frequent targets of impersonation emails.
Reads the _dmarc TXT record for the domain or its organizational domain and checks the policy.
DMARC tells receiving mail servers to reject mail that fails authentication — the main defence against spoofed announcements from your domain.
Frontend & disclosure
Parses the homepage HTML for scripts, frames, stylesheets and media loaded over plain HTTP.
A single script loaded over HTTP lets a network attacker run code on an otherwise secure page.
Lists scripts loaded from other domains and checks whether they use Subresource Integrity (integrity attribute).
Compromised third-party scripts are a leading cause of wallet-drainer incidents. SRI makes the browser refuse a script that has been altered.
Requests /.well-known/security.txt and checks it contains a Contact field and has not expired.
Gives researchers a clear way to report vulnerabilities privately instead of disclosing them publicly.
Web3 frontend
Reads the homepage HTML and up to 8 of its JavaScript files (including chunks they import) and looks for explicit references to package releases that were published with malicious code, such as @ledgerhq/connect-kit 1.1.5–1.1.7 and @solana/web3.js 1.95.6–1.95.7.
These releases shipped wallet drainers or key stealers to every site that loaded them. A reference means visitors may have been exposed.
Looks for wallet or chain libraries fetched at runtime from public CDNs (jsDelivr, unpkg, esm.sh, Skypack) without an exact version.
Loading the latest release at runtime means a compromised package reaches users within minutes, with no build step in between. This is how the Ledger Connect Kit incident spread.
Follows sourceMappingURL comments in the site's own scripts (up to 3) and checks whether the source map can be downloaded.
Public source maps reveal the original, unminified application code, which makes logic flaws and hidden endpoints easier to find.
Extracts EVM addresses referenced in the page code (up to 6) and checks Sourcify for verified source on Ethereum, Base, Arbitrum, OP Mainnet, Polygon and BNB Chain.
Users should be able to read the code they're asked to interact with. Unverified addresses aren't necessarily unsafe, so this is informational only.
Limitations
- This is a public, non-invasive assessment of externally visible configuration. It does not test application logic, authentication, APIs, smart contracts or wallet flows.
- Only the homepage, up to 8 of the scripts it loads, and a few well-known paths were requested. Other pages, lazy-loaded code and subdomains may be configured differently.
- A good grade means the checked controls are in place. It does not prove the application is secure.
- Some networks refuse raw TLS probes from our cloud scanners. When that happens the legacy-TLS check is marked as not assessed instead of guessed.
Opt out, dispute a result, or report abuse
Domain owners can ask us to stop assessing their domain and hide its public reports. Opt-outs cover all subdomains. If you believe a finding is wrong, or that our scanner was used against you abusively, contact us and we'll respond within two business days. Severe issues found during verified testing are always disclosed privately.
security@pentestagent.dev