Hidden inputs named like tokens or secrets are visible to anyone reading the HTML. Reported for review - CSRF tokens are legitimate here, API keys are not.
- Free, no signupNo account, no card
- No AI in the score986 deterministic rules
- Nothing publishedYour scans stay yours
- Answers in secondsQuick scan, no browser
How this rule is weighted
- Importance
- 3 / 10
- How much this matters relative to other rules.
- Confidence
- SPECIFICATION
- A standard says so: HTML, WCAG, an RFC or Google's own documentation.
- Severity
- info
- How the finding is presented when it fails.
- Scoring
- Excluded
- Reported in the report, never penalised.
Impact is importance multiplied by the confidence tier’s weight — SPECIFICATION 1.0, RESEARCH 0.7, EMERGING 0.3, EXPERIMENTAL 0.1. Two rules backed by the same class of evidence therefore always carry the same weight, which is what makes the score reproducible rather than hand-tuned.
Questions about this rule
- Does SEC_HIDDEN_SENSITIVE_INPUTS affect my score?
- No. It is a detection rule: it runs, appears in your report and never penalises you. "Sensitive-looking hidden fields detected" is information about the page rather than a defect - most pages are not expected to satisfy it.
- What does SPECIFICATION confidence mean?
- A standard says so: HTML, WCAG, an RFC or Google's own documentation. Confidence is a declared tier rather than a per-rule number, so every rule backed by the same class of evidence carries the same weight - which is what makes the score reproducible instead of hand-tuned.
- How do I check SEC_HIDDEN_SENSITIVE_INPUTS on my own site?
- Paste your URL into the box above and it runs only this rule, usually in a couple of seconds. It is also included in the Security checker and in a full scan.
Tags
- security
- information-disclosure
Related Security rules
- Certificate chain validates against the public trust storeCompletes a real TLS handshake and checks whether the presented certificate chain validates against the system trust store. A chain that does not validate produces a full-page browser interstitial - the single most damaging thing that can happen to a page, and one no response-header check can detect.SEC_TLS_CERT_TRUSTED
- Site is served over HTTPSThe page must be served over HTTPS, not plain HTTP.SEC_HTTPS
- Certificate covers the hostname being servedChecks the scanned hostname against the certificate's subject alternative names, including wildcard entries. A certificate that does not cover the hostname triggers the same interstitial as an expired one, and it is easy to miss when the apex and www forms are configured separately.SEC_TLS_HOSTNAME_COVERED
- No passwords submitted via GETA GET form puts the password in the URL, where it lands in browser history, server logs and referrer headers.SEC_FORM_METHOD_GET_SENSITIVE
- Certificate is not close to expiryReads the leaf certificate's expiry date from the handshake. An expired certificate blocks the entire site behind an interstitial, and because renewal is usually automated, the failure mode is silent right up until it is total.SEC_TLS_CERT_NOT_EXPIRING
- Connection negotiates TLS 1.2 or betterReports the protocol version actually negotiated. RFC 8996 deprecated TLS 1.0 and 1.1 in 2021; browsers now warn or refuse outright, and PCI DSS has prohibited them for card handling since 2018.SEC_TLS_PROTOCOL_MODERN