Security & reputation hardening prompt — 2050planet.com
Paste this into an AI coding assistant that has access to the 2050planet.com codebase and deployment. Work through it in order. Do not skip ahead to the technical hardening — the reputation and cleanup steps come first on purpose, because they are the site's real exposure.
---
Context you must respect
This is a live, public content platform aimed at governments, ministries, and schools. Two failure modes are worse than being slightly under-hardened:
1. **Breaking a feature.** Three things must keep working no matter what: the **Carbon Scanner** (uses the device camera), **Ask TERRA** (an AI assistant that calls an API), and **Arabic / RTL content and search** (part of a 10-language roadmap). If a security change would touch any of these, stop and flag it instead of proceeding.
2. **Downtime or lockout.** A ministry procurement team hitting an error, a locked-out user, or a site that won't load over HTTPS is a bigger problem than a missing header.
Reputation is part of security here. The site must look and behave like institutional infrastructure.
---
Step 1 — Inspect and report. Change nothing yet.
Report back on all of the following before touching anything:
- **Hosting and stack**: where the site is deployed (Vercel, Netlify, Cloudflare Pages, a container, a VPS, a managed host), the framework, and whether there is already a CDN or reverse proxy in front.
- **Can a proxy even be added?** State plainly whether the hosting lets you run your own reverse proxy in front of the app, or whether hardening has to happen through platform settings and a DNS-level layer instead. This decides the whole approach later.
- **Current response headers**, in full, including any `Server`, `X-Powered-By`, or version banner, and every cookie set.
- **Canonical host**: the site is reachable as both `2050planet.com` and `www.2050planet.com`, and the canonical tag points at the bare domain while navigation links use `www`. Report which host actually serves, and whether one redirects to the other.
- **Old-install remnants**: search the deployment for anything left from a previous WordPress install — PHP files, `wp-login.php`, `xmlrpc.php`, `wp-admin`, `wp-content`, `.htaccess`, uploads directories, unknown admin accounts, scheduled tasks, or database tables. Report what exists and what is reachable from the public internet.
- **Search Console access**: whether the site is verified in Google Search Console, since the cleanup step needs it.
Show me this inventory and wait for my confirmation before making changes.
---
Step 2 — Clean the search reputation (highest priority)
Google's index currently contains casino spam pages under this domain (titles like "Casino Machine Online", "New Independent Casinos"), on old WordPress-style URLs such as `/uncategorized/...` and `/?p=NNNN`. This is the residue of a past compromise. The pages themselves now 404, but they are still indexed, and old query-string URLs like `/?p=4868` currently return the homepage with a `200` status — a soft 404 that keeps Google holding onto them.
Do the following:
- Make every old spam URL and old WordPress URL pattern return **`410 Gone`** (for spam that should vanish) or a **`301` redirect** to the correct current page (for legitimate old content that moved). Do not let any of them return `200` with homepage content.
- Cover the patterns: `/?p=<number>`, `/uncategorized/*`, `wp-*` paths, and any `/category/*` path that does not map to a real current section.
- In Google Search Console, submit removal requests for the spam URLs and request re-indexing of the real pages.
- Confirm the spam is not reachable and not regenerating.
---
Step 3 — Confirm the old install is fully gone
Using the inventory from Step 1, remove anything left from the prior WordPress install: orphaned files, PHP endpoints, upload directories, unknown accounts, injected cron jobs, and database remnants. Verify that `wp-login.php`, `xmlrpc.php`, `wp-admin`, and `wp-content` all return `404`/`410` and are not serving anything. A compromise that got in once leaves a way back in if remnants stay.
---
Step 4 — Protect Ask TERRA (the AI assistant)
An unmetered, public AI endpoint is the most exploitable surface on the site — it can be drained for cost, abused as a free model proxy, or prompt-injected. Harden it:
- **Verify the model provider key is server-side only.** It must never appear in client code or network calls the browser can read. If it is exposed, this is the first thing to fix.
- **Rate-limit per session and per IP**, with a stricter ceiling than the rest of the site.
- **Set a daily/monthly spend cap** with an alert well before the cap, so a bot wave can't run up an unbounded bill.
- **Cap input length** and reject oversized or malformed requests.
- **Scope it.** TERRA should answer for this platform's subject matter, not act as a general-purpose assistant for whatever anyone pastes in. Handle prompt-injection and off-topic bulk use.
- **Restrict the endpoint** to calls originating from the site's own origin.
- **Log abuse attempts** (rate hits, oversized inputs, injection patterns) without logging full conversation contents.
- **Check where TERRA's calls go.** Since the platform targets governments, confirm the data path for the AI calls is acceptable for that audience, and tell me if it routes through a third party in a way that conflicts with keeping data internal.
---
Step 5 — Protect the Carbon Scanner without disabling it
The scanner needs the camera. So:
- Set `Permissions-Policy` to **allow `camera` on the scanner route only** (`self`), and deny it everywhere else. Do not issue a blanket camera denial — that breaks the feature.
- If the scanner uploads or processes images server-side, cap file size and request rate so it can't be used as an open image-processing endpoint. If it runs entirely on-device, note that and move on.
---
Step 6 — Headers and CSP, built from what the site actually loads
Do not paste a template CSP. Build it from the site's real dependencies, or it will silently break TERRA and the scanner.
- Inventory what the pages legitimately load: the TERRA API endpoint(s), font and asset sources, image sources (including the scanner's), and any inline styles/scripts the build emits.
- Deploy `Content-Security-Policy` in **report-only mode first**, pointing `report-to`/`report-uri` at a real collector endpoint you set up — not the browser console. Show me the violation reports. Only switch to enforcing after TERRA, the scanner, Arabic pages, and search all report clean.
- Add the rest at the edge so no route misses them:
- `Strict-Transport-Security` — **start with a max-age of a few minutes**, confirm HTTPS is solid everywhere, then raise it over weeks. Do not deploy a long max-age immediately; it is not reversible once browsers cache it.
- `X-Content-Type-Options: nosniff`
- `Referrer-Policy: strict-origin-when-cross-origin`
- `X-Frame-Options: DENY` (or CSP `frame-ancestors 'none'`)
- Remove `Server`, `X-Powered-By`, and any version banner. (Do this, but treat it as the least important item here — it's obscurity, not defense.)
- Any cookie the site sets gets `Secure`, `SameSite`, and `HttpOnly` unless JavaScript genuinely needs to read it.
- **Pick one canonical host.** Redirect `www` to bare (or the reverse) with a `301`, and keep it consistent — this matters for HSTS, cookies, and the SEO cleanup above.
---
Step 7 — Rate limiting that respects real traffic
- Be **generous on `/search` and content routes** — search is primary navigation across 255+ articles, and readers browse fast. Do not throttle these tightly.
- Apply tighter limits to **TERRA, the contact form, and any write or auth path**.
- If anything (a CDN, a platform edge) sits in front, derive the real client IP from **trusted forwarded headers only** — otherwise every visitor looks like one IP and you throttle the whole internet at once, or nobody.
- Return a plain `429` with no internal detail. Do not silently ban IP ranges.
---
Step 8 — A WAF, only if it fits, and only in detection mode
- **If the hosting lets you run an edge proxy**: add a WAF using the OWASP Core Rule Set (Coraza on Caddy/Traefik/Envoy). **If it's a managed platform** (Vercel, Netlify, etc.) where you can't: use the platform's native protections plus a DNS-level WAF such as Cloudflare instead. Do not fake a proxy layer the host doesn't support.
- **Start in detection-only mode** — log what would be blocked, block nothing. I review the logs and decide when to switch.
- **Tune for non-Latin scripts before enabling blocking.** The Core Rule Set is tuned on Latin traffic and will false-positive on Arabic input, RTL text, and mixed-script search queries. Keep it in detection mode until Arabic search and Arabic form input are confirmed clean. This is non-negotiable given the Arabic-first roadmap.
- **Any AI-generated firewall rule requires my approval before it goes live.** A generated rule can block real users or be trivially bypassed while looking like protection.
---
Step 9 — Logging you can operate
- Structured JSON, one record per event: timestamp, source IP, path, matched rule (if any), action taken.
- **Rotate logs, cap their size, and set a retention limit.** Unbounded logs fill the disk and take the site down.
- Treat **IP addresses and full URLs as personal data** (they are, under UAE and EU law). Set a retention window, state the basis, and do not log request bodies, tokens, or personal data.
- Alert on disk usage and on the TERRA spend threshold.
---
Step 10 — Verify with evidence, then summarize
Confirm each, with proof, before calling it done:
- Old spam and WordPress URLs return `410`/`301`, and removals are submitted in Search Console.
- `wp-login.php`, `xmlrpc.php`, `wp-admin`, `wp-content` are gone / return `404`.
- HTTPS works, HTTP redirects to it, the certificate auto-renews, and a single canonical host serves.
- **The Carbon Scanner opens the camera and works.**
- **Ask TERRA still answers**, and a test flood trips the rate limit and spend guard as intended.
- **An Arabic page loads and an Arabic (and mixed-script) search query is not blocked.**
- Search and the contact form work under normal use.
- No response header names the server software or version; CSP is enforced without breaking TERRA or the scanner.
Then write a short summary: what changed, what is now blocked or merely logged, what still needs my decision, and what would break if detection mode were switched to blocking today.
---
Rules for the whole job
- Work on **staging or during a declared maintenance window** — not by experimenting on the live production site.
- **Back up every config file you edit**, and keep a one-command rollback.
- Change **one layer at a time** and confirm the site — including the scanner, TERRA, and an Arabic page — still works before moving to the next.
- **HSTS is a one-way door**: short max-age first, ramp up later.
- **Never disable an existing security control** to make something work. Flag the conflict instead.
- **AI-generated rules need my sign-off** before deployment.
- If any step could take the site down even briefly, **stop and ask me first**.
---
After it's running — operating this
Hardening isn't one-time. Set up: certificate-renewal monitoring, ruleset updates, log rotation checks, TERRA spend and abuse alerts going to someone who reads them, a periodic Search Console check for re-injected spam, and regular dependency patching. Decide who owns each of these.