The security scan of chess.com found 13 medium and low severity issues. No critical vulnerabilities were detected, but 3 issues should be addressed this week to harden your security posture. Detailed fix instructions are included for each finding.
Cookie 'psid' is missing the HttpOnly flag(s). Observed attributes: expires=Tue, 15 Sep 2026 06:35:22 GMT, Max-Age=1800, path=/, domain=chess.com, secure, samesite=lax.
This cookie's name suggests it may hold a session or authentication token, though its actual contents weren't inspected. If it does, a cookie missing these flags is easier to steal through cross-site scripting or to intercept over an unencrypted connection — and a stolen session cookie can let an attacker impersonate that logged-in user without ever needing their password.
Example: A visitor on public wifi has their session cookie intercepted because it wasn't marked Secure, or a malicious ad script reads it directly because it wasn't marked HttpOnly — either way, the attacker is now logged in as that user without ever seeing their password.
Add the missing flag(s) when setting this cookie: Secure (only send over HTTPS), HttpOnly (block JavaScript access), SameSite=Lax or Strict (limit cross-site sending). Most frameworks expose this as a one-line config option — e.g. Flask: app.config['SESSION_COOKIE_SECURE']=True, SESSION_COOKIE_HTTPONLY=True, SESSION_COOKIE_SAMESITE='Lax'.
CWE-1004 — Sensitive Cookie Without 'HttpOnly' Flag
The cookie isn't marked HttpOnly, so a malicious script on the page (such as one injected via XSS) can read and steal it.
DKIM key for selector 's2' appears to be approximately 1024 bits — 1024-bit RSA keys are considered weak by modern standards and NIST has deprecated them. A well-resourced attacker could factor this key, breaking your email authentication.
A forged DKIM signature lets an attacker send phishing or fraud emails that cryptographically appear to come from your domain — bypassing email filters that rely on DKIM as a trust signal, and making impersonation emails indistinguishable from your real ones.
Example: A security researcher demonstrated in a published study that 512-bit DKIM keys could be factored in under 72 hours using cloud computing resources costing less than $100 — allowing anyone with that capability to forge valid email signatures for the affected domain.
Upgrade the DKIM key for selector 's2' to 2048 bits. Generate a new key through your email provider, update the DNS TXT record to the new public key, and retire the old 1024-bit key.
CSP script-src allows 'unsafe-eval' — an injected or hijacked script can still run freely
This setting defeats most of the protection CSP is meant to provide. If a third-party script you rely on is ever compromised — the exact mechanism behind most 'watering hole' attacks — it will execute without restriction and with no warning.
Example: A vendor's analytics or chat-widget script gets compromised at the source; because the policy still allows it (or allows inline/eval scripts generally), the malicious code runs exactly as if it belonged on the site, with no warning to anyone.
Tighten script-src to an explicit allowlist of trusted domains and drop 'unsafe-inline'/'unsafe-eval'/wildcards. Move inline scripts to external files or use a nonce/hash. Test changes with https://csp-evaluator.withgoogle.com before deploying.
CWE-693 — Protection Mechanism Failure
A security safeguard that should be protecting the system is missing, disabled, or not strong enough.
Public IP 104.18.137.67 (hosted by Cloudflare, Inc.) has an abuse confidence score of 0/100 from 3 report(s) in the last 90 days on AbuseIPDB.
A flagged IP usually means one of two things: this server has already been compromised and is being used to send spam or attack other systems, or this is a shared-hosting IP where a different customer on the same server is doing something malicious — either way, some mail providers and firewalls will treat traffic from this IP with extra suspicion, which can affect email deliverability and how visitors' security software treats your site.
If this is a dedicated server, check for signs of compromise (unexpected processes, outbound traffic, unfamiliar scheduled tasks) and consider a malware scan. If this is shared hosting, contact your hosting provider — ask whether the IP is shared and whether they can move you to a clean one. You can see the specific reports at https://www.abuseipdb.com/check/104.18.137.67.
Missing Referrer-Policy — page URLs (which may include sensitive data) are shared with third-party sites your pages link to
If any of your page addresses contain sensitive details (like a password-reset token or account ID), that information could leak to outside sites your pages link to — a small but easily avoidable privacy gap.
Example: A customer clicks an outbound link from a page whose URL happens to include an account ID or a password-reset token, and that full address — token included — is handed to the destination site in the Referer header.
Add: 'add_header Referrer-Policy "strict-origin-when-cross-origin" always;' (Nginx) or 'Header always set Referrer-Policy strict-origin-when-cross-origin' (Apache).
CWE-16 — Configuration
The weakness comes from how the software was configured, not from a flaw in its code.
Missing Permissions-Policy — browser features like camera, microphone, and location aren't restricted for embedded third-party scripts
If you ever embed third-party ads, widgets, or analytics scripts, they could request a visitor's camera, microphone, or location without you intending to allow it — an avoidable privacy risk for your customers.
Example: An embedded ad network's script requests the visitor's location or microphone access through a permission prompt the site owner never intended to allow, simply because nothing in the page's headers restricted it.
Add: 'add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;' Adjust based on what your site actually uses. This limits what ad/analytics scripts can access.
CWE-693 — Protection Mechanism Failure
A security safeguard that should be protecting the system is missing, disabled, or not strong enough.
Cookie 'ATTRIBUTION_V1' is missing the Secure, HttpOnly flag(s). Observed attributes: expires=Thu, 15 Oct 2026 06:05:22 GMT, Max-Age=2592000, path=/, domain=chess.com, samesite=lax.
This cookie's name doesn't clearly indicate it holds session or authentication data, so the practical impact depends on what value it actually stores — anywhere from low-stakes (a UI preference) to more sensitive (tracking or personalization data). Missing these flags means whatever the cookie does hold is more exposed than it needs to be to interception or script access.
Example: whatever value 'ATTRIBUTION_V1' holds could be read by an injected script (no HttpOnly) or intercepted on an unencrypted connection (no Secure) — the actual severity depends on how sensitive that value turns out to be.
Add the missing flag(s) when setting this cookie: Secure (only send over HTTPS), HttpOnly (block JavaScript access), SameSite=Lax or Strict (limit cross-site sending). Most frameworks expose this as a one-line config option — e.g. Flask: app.config['SESSION_COOKIE_SECURE']=True, SESSION_COOKIE_HTTPONLY=True, SESSION_COOKIE_SAMESITE='Lax'.
CWE-614, CWE-1004 — Sensitive Cookie in HTTPS Session Without 'Secure' Attribute; Sensitive Cookie Without 'HttpOnly' Flag
The cookie isn't marked Secure, so a browser could send it over an unencrypted connection where it can be intercepted. The cookie isn't marked HttpOnly, so a malicious script on the page (such as one injected via XSS) can read and steal it.
Cookie 'me' is missing the Secure, HttpOnly flag(s). Observed attributes: expires=Wed, 15 Sep 2027 06:05:22 GMT, Max-Age=31536000, path=/, domain=chess.com, samesite=strict.
This cookie's name doesn't clearly indicate it holds session or authentication data, so the practical impact depends on what value it actually stores — anywhere from low-stakes (a UI preference) to more sensitive (tracking or personalization data). Missing these flags means whatever the cookie does hold is more exposed than it needs to be to interception or script access.
Example: whatever value 'me' holds could be read by an injected script (no HttpOnly) or intercepted on an unencrypted connection (no Secure) — the actual severity depends on how sensitive that value turns out to be.
Add the missing flag(s) when setting this cookie: Secure (only send over HTTPS), HttpOnly (block JavaScript access), SameSite=Lax or Strict (limit cross-site sending). Most frameworks expose this as a one-line config option — e.g. Flask: app.config['SESSION_COOKIE_SECURE']=True, SESSION_COOKIE_HTTPONLY=True, SESSION_COOKIE_SAMESITE='Lax'.
CWE-614, CWE-1004 — Sensitive Cookie in HTTPS Session Without 'Secure' Attribute; Sensitive Cookie Without 'HttpOnly' Flag
The cookie isn't marked Secure, so a browser could send it over an unencrypted connection where it can be intercepted. The cookie isn't marked HttpOnly, so a malicious script on the page (such as one injected via XSS) can read and steal it.
Cookie 'BUCKETING_ID_V2' is missing the HttpOnly flag(s). Observed attributes: expires=Wed, 15 Sep 2027 06:05:22 GMT, Max-Age=31536000, path=/, domain=chess.com, secure, samesite=lax.
This cookie's name doesn't clearly indicate it holds session or authentication data, so the practical impact depends on what value it actually stores — anywhere from low-stakes (a UI preference) to more sensitive (tracking or personalization data). Missing these flags means whatever the cookie does hold is more exposed than it needs to be to interception or script access.
Example: whatever value 'BUCKETING_ID_V2' holds could be read by an injected script (no HttpOnly) or intercepted on an unencrypted connection (no Secure) — the actual severity depends on how sensitive that value turns out to be.
Add the missing flag(s) when setting this cookie: Secure (only send over HTTPS), HttpOnly (block JavaScript access), SameSite=Lax or Strict (limit cross-site sending). Most frameworks expose this as a one-line config option — e.g. Flask: app.config['SESSION_COOKIE_SECURE']=True, SESSION_COOKIE_HTTPONLY=True, SESSION_COOKIE_SAMESITE='Lax'.
CWE-1004 — Sensitive Cookie Without 'HttpOnly' Flag
The cookie isn't marked HttpOnly, so a malicious script on the page (such as one injected via XSS) can read and steal it.
Cookie 'visitorid' is missing the Secure flag(s). Observed attributes: expires=Wed, 15 Sep 2027 06:05:22 GMT, Max-Age=31536000, path=/, httponly, samesite=lax.
This cookie's name doesn't clearly indicate it holds session or authentication data, so the practical impact depends on what value it actually stores — anywhere from low-stakes (a UI preference) to more sensitive (tracking or personalization data). Missing these flags means whatever the cookie does hold is more exposed than it needs to be to interception or script access.
Example: whatever value 'visitorid' holds could be read by an injected script (no HttpOnly) or intercepted on an unencrypted connection (no Secure) — the actual severity depends on how sensitive that value turns out to be.
Add the missing flag(s) when setting this cookie: Secure (only send over HTTPS), HttpOnly (block JavaScript access), SameSite=Lax or Strict (limit cross-site sending). Most frameworks expose this as a one-line config option — e.g. Flask: app.config['SESSION_COOKIE_SECURE']=True, SESSION_COOKIE_HTTPONLY=True, SESSION_COOKIE_SAMESITE='Lax'.
CWE-614 — Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
The cookie isn't marked Secure, so a browser could send it over an unencrypted connection where it can be intercepted.
Cookie 'BUCKETING_ID' is missing the HttpOnly flag(s). Observed attributes: path=/, domain=.chess.com, secure, samesite=lax.
This cookie's name doesn't clearly indicate it holds session or authentication data, so the practical impact depends on what value it actually stores — anywhere from low-stakes (a UI preference) to more sensitive (tracking or personalization data). Missing these flags means whatever the cookie does hold is more exposed than it needs to be to interception or script access.
Example: whatever value 'BUCKETING_ID' holds could be read by an injected script (no HttpOnly) or intercepted on an unencrypted connection (no Secure) — the actual severity depends on how sensitive that value turns out to be.
Add the missing flag(s) when setting this cookie: Secure (only send over HTTPS), HttpOnly (block JavaScript access), SameSite=Lax or Strict (limit cross-site sending). Most frameworks expose this as a one-line config option — e.g. Flask: app.config['SESSION_COOKIE_SECURE']=True, SESSION_COOKIE_HTTPONLY=True, SESSION_COOKIE_SAMESITE='Lax'.
CWE-1004 — Sensitive Cookie Without 'HttpOnly' Flag
The cookie isn't marked HttpOnly, so a malicious script on the page (such as one injected via XSS) can read and steal it.
Public IP 104.18.137.67 is registered to Cloudflare, Inc. — network: CLOUDFLARENET — block: 104.16.0.0 – 104.31.255.255.
This is informational — it tells you (and anyone else who looks it up) which hosting provider or network actually operates this IP. Useful for confirming you're hosted where you expect, or for context if the IP reputation check above flags anything.
No action required — this is identifying information, not a vulnerability.
The target began responding with repeated rate-limit/unavailable statuses, so the remaining 89 path(s) in this scan were skipped rather than risk overloading the server.
The target began responding with repeated rate-limit/unavailable statuses, so the remaining 89 path(s) in this scan were skipped rather than risk overloading the server.
Re-run content discovery later, or use a lower-concurrency profile.
No high-risk open ports were detected from the internet — your firewall appears to be blocking dangerous services.