The security scan of newgrounds.com found 6 issues including 1 high-risk and 3 medium-risk findings. The most critical issue is 'Domain Expiring in 16 Days — Urgent' which requires immediate attention. Full remediation steps are provided for each finding below.
Domain registration expires in 16 days (registrar: TUCOWS.COM, CO.) — losing it would take down the website and all email
If this renewal is missed, the website goes offline and every email address on this domain stops working — including invoices, password resets, and customer replies — until it's renewed or, worst case, recovered from whoever registers it after it lapses.
Example: The card on file for auto-renew has expired without anyone noticing; unless someone renews manually in the next few days, the site and every email address on the domain go dark with no advance warning to customers.
Renew the domain now at your registrar — 16 days left. Turn on auto-renew and confirm the card on file and contact email are current so this never happens silently again.
Missing Strict-Transport-Security (HSTS) — browsers aren't forced to always use HTTPS, leaving visitors open to downgrade attacks
An attacker on the same network as a visitor (public wifi, a compromised router, etc.) can trick their browser into using the insecure version of your site and intercept what they type — raising the odds of stolen logins or payment details.
Example: An attacker on a shared network intercepts a visitor's first request (which defaults to HTTP) before the redirect happens, and silently serves them a fake version of the page instead of the real site.
Add the HSTS header to your web server. Nginx: add 'add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;' in your server block. Apache: add 'Header always set Strict-Transport-Security "max-age=31536000"' in your config. Cloudflare: SSL/TLS > Edge Certificates > enable HTTP Strict Transport Security.
CWE-319 — Cleartext Transmission of Sensitive Information
Sensitive data is sent over the network unencrypted, so anyone monitoring the connection can read it.
DMARC is set to monitor-only (p=none) — phishing emails pretending to be you aren't blocked, just reported
Phishing emails pretending to be your business can still reach customers' inboxes today — you'll get aggregate reports about it after the fact (if 'rua=' reporting is configured), but nothing actually stops the fraudulent emails from being delivered right now. p=none is a legitimate and recommended first step — it lets you review reports and confirm all your real mail sources pass DMARC alignment (the From-header domain matching either an aligned SPF pass or an aligned DKIM signature) before you start blocking anything — the risk is only in staying at p=none indefinitely instead of using it as a monitoring phase.
Example: Forged emails impersonating the business keep reaching customers' inboxes; DMARC reports quietly pile up showing exactly that it's happening, but because the policy is monitor-only, nothing actually blocks a single one of them.
Review DMARC aggregate reports (they require 'rua=mailto:...' in the record) for a few weeks to confirm every legitimate mail source for this domain is passing DMARC alignment. Once confirmed, move to 'p=quarantine' (suspicious mail goes to spam) and monitor again before finally moving to 'p=reject' (spoofed mail is rejected outright). Don't jump straight to p=reject — if a legitimate sender was missed, that skips straight to real mail being dropped. Example: 'v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com'
CWE-290 — Authentication Bypass by Spoofing
The login or identity check can be tricked by faking trusted information, letting an attacker in without real credentials.
No DKIM record found under common selector names — this does not confirm DKIM is unconfigured, only that it wasn't found under any of the selector names checked; many providers use a custom or provider-specific selector this check can't guess
If DKIM genuinely isn't configured, email providers increasingly use it as a trust signal, and its absence can make legitimate emails more likely to be flagged as suspicious or land in spam. But this check only queries a fixed list of common selector names (default, google, mail, etc.) — many providers assign a random or account-specific selector, so this finding should be treated as 'couldn't confirm DKIM,' not 'DKIM is definitely missing.'
Example: A legitimate invoice email from the business gets flagged as suspicious or dropped into spam by the recipient's mail provider, simply because there's no DKIM signature to prove the message wasn't altered or forged in transit — this only actually happens if DKIM is truly unconfigured, which this check alone can't confirm.
First confirm whether DKIM is actually configured: check your email provider's admin console (Google Workspace: Admin console > Apps > Gmail > Authenticate email; Microsoft 365: Defender > Email authentication > DKIM) for the exact selector name in use, since it's often not one of the common defaults this scan checks. If it turns out DKIM genuinely isn't enabled, turn it on there and add the resulting TXT record to DNS. If you're not sure how to check, share the selector name your provider gives you and this can be verified directly.
CWE-290 — Authentication Bypass by Spoofing
The login or identity check can be tricked by faking trusted information, letting an attacker in without real credentials.
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.
Public IP 15.235.14.84 (hosted by OVH Hosting, Inc.) has no abuse reports on AbuseIPDB in the last 90 days.
A clean IP reputation is a good sign — no other indication needed here.
No action required.
Your server is reachable, which means the web checks and SSL analysis were able to run successfully.