Date: 2026-10-24 · Prepared by: Next Maintainer · Type: External check (no access to your systems)
Overall: 🔴 Needs attention
We found 1 high-priority and 3 medium-priority issues visible from the outside. The most important: nginx 1.22.0 is end-of-life since 2023-04-11; and 5 recommended security header(s) missing. Nothing here suggests a rewrite. These are routine fixes for an experienced engineer, but the risk grows the longer they wait.
| # | Issue | Why it matters to you | Effort |
|---|---|---|---|
| 1 | 🔴 nginx 1.22.0 is end-of-life since 2023-04-11 | Security holes found in this version will never be patched. Hosting providers also eventually force upgrades, often at short notice. | Medium |
| 2 | 🟠 5 recommended security header(s) missing | These headers tell browsers to block common attacks such as clickjacking and some script injection. They are cheap protection that most modern sites set. | Low |
| 3 | 🟠 No SPF record | Your emails (invoices, password resets) are more likely to land in spam, and others can more easily send email pretending to be you. | Low |
🔴 nginx 1.22.0 is end-of-life since 2023-04-11
Detected via Server header. Version line 1.22 no longer receives fixes; current is 1.31.8.
Why it matters: Security holes found in this version will never be patched. Hosting providers also eventually force upgrades, often at short notice.
Fix: Plan an upgrade to a supported nginx version, with testing.
🟠 5 recommended security header(s) missing
Missing: Strict-Transport-Security (HSTS), Content-Security-Policy, X-Frame-Options / frame-ancestors, X-Content-Type-Options, Referrer-Policy.
Why it matters: These headers tell browsers to block common attacks such as clickjacking and some script injection. They are cheap protection that most modern sites set.
Fix: Add the headers in the web server or framework config, testing CSP carefully so nothing breaks.
🟡 Server reveals exact software versions
server: nginx/1.22.0
Why it matters: Publishing exact versions makes it easy for automated attack tools to pick known exploits for your setup.
Fix: Hide version numbers in the web server / PHP configuration (e.g. server_tokens off, expose_php Off).
🟠 No SPF record
jobboard.example publishes no SPF record listing which servers may send its email.
Why it matters: Your emails (invoices, password resets) are more likely to land in spam, and others can more easily send email pretending to be you.
Fix: Publish an SPF record listing your mail providers.
🟠 No DMARC policy
_dmarc.jobboard.example has no DMARC record.
Why it matters: Without DMARC, anyone can send emails that look like they come from your domain (a common phishing trick), and Gmail/Yahoo increasingly reject or spam-folder such mail.
Fix: Publish a DMARC record, start with monitoring (p=none), then tighten to quarantine/reject.
⚪ DKIM signing not found under common selectors
Checked: google, selector1, selector2, default, k1, mail, s1, s2, dkim, smtp, mandrill, mailjet. DKIM may still exist under a custom selector.
Why it matters: DKIM cryptographically signs your emails; without it deliverability suffers.
Fix: Confirm DKIM is enabled with your email provider.
🟡 Pages are sent uncompressed
HTML is 70 KB with no gzip/brotli compression.
Why it matters: Compression typically cuts page size by 70% or more, making the site faster on mobile.
Fix: Enable gzip or brotli in the web server.
✅ No issues found in this area.
| Component | Version | Status | Known vulnerabilities | Detected via |
|---|---|---|---|---|
| nginx | 1.22.0 | 🔴 end-of-life (current: 1.31.8) | 0 | Server header |
HTTPS certificate: Let's Encrypt, valid until Dec 5 23:55:52 2026 GMT (42 days), protocol TLSv1.3.
Email: SPF ❌ · DMARC ❌ · DKIM not found under common selectors.
Performance (single sample): 141 ms to first byte, 70 KB HTML, compression: none.
1. Plan an upgrade to a supported nginx version, with testing.
2. Add the headers in the web server or framework config, testing CSP carefully so nothing breaks.
3. Publish an SPF record listing your mail providers.
4. Publish a DMARC record, start with monitoring (p=none), then tighten to quarantine/reject.
5. Hide version numbers in the web server / PHP configuration (e.g. server_tokens off, expose_php Off).
6. Get read access to the code and server: check dependencies, backups (with a test restore), deploys and monitoring. That is what this external check cannot see.
Happy to walk you through this in a 20-minute call, with no obligation. Just reply to this email.
Method: this check used only publicly available information: the home page and the files it loads, HTTP headers, the TLS certificate and public DNS records. Version data comes from endoflife.date, and vulnerability data from OSV.dev. At the owner's request, we also checked a short list of well-known sensitive file paths. No login attempts, no vulnerability exploitation, and no load testing were performed. Results are a snapshot and may contain false positives.