A vulnerability report that says "add a Content-Security-Policy header" and stops there leaves the actual work - figuring out the right syntax for your specific server, your specific framework - entirely to the reader. Shieldome generates the next step directly: concrete fix steps and copy-pasteable configuration, scoped to the technology stack it actually detected during the scan, not a generic template.

Remediation Steps Are Scoped to What Was Actually Detected

The remediation prompt is given the confirmed tech stack from the scan and is explicitly told not to go beyond it - if nothing was detected, it's instructed to give generic web-server fix steps only, and it's told directly not to assume PHP, Laravel, Rails, WordPress, or any framework that wasn't actually confirmed. This matters because a fix suggestion built on a wrong assumption about your stack is worse than no suggestion at all - it wastes the time of whoever has to realize it doesn't apply and then find the real fix themselves.

Config Snippets, Not Just Prose

For findings where an actual configuration change is the fix - missing security headers, weak TLS settings, missing rate limiting - a separate step generates ready-to-paste snippets for each relevant environment: Nginx, Apache, Express.js, Django, Flask, Laravel, Next.js, IIS, Cloudflare, and others, but again only for the environments that match the detected stack.

# Example output for a missing Strict-Transport-Security header on an Nginx target
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Framework-specific configuration syntax is exactly the kind of detail that's easy to get subtly wrong by hand - a header set in the wrong context block, a directive that needs an additional flag in a newer version - so having it generated against the stack that was actually observed removes an entire class of "the fix didn't actually work" follow-up.

Context Changes the Fix: The Typosquat Case

Not every finding has a fix that lives on your own server, and the remediation logic accounts for that explicitly. For a typosquatting finding - a lookalike domain registered by someone else - the model is given a hard constraint: those domains are hosted on third-party infrastructure, so an Nginx RewriteRule or any server-side blocking config on your own server would have zero effect, since requests to the typo domain never reach your server in the first place. The only remediation steps offered for this finding type are the ones that actually work - contacting the registrar for a takedown, registering the obvious typo variants yourself, and using DMARC so the lookalike domain can't spoof mail as if it were yours.

Plain-English CVE Impact

When a finding involves a known CVE in a detected component, a separate short explanation translates the CVE into what it actually means for that specific site - what an attacker could do, and how urgent it is for a typical production deployment - deliberately avoiding CVE-number jargon in favor of plain language a non-security engineer can act on immediately.

Cached, Not Regenerated Every Time

Remediation and config snippet results are cached for seven days, keyed by the finding's content and the detected tech stack. The same finding showing up on a later scan of the same site returns instantly rather than re-generating an identical answer - the cache key changes automatically the moment the finding or the stack actually changes.

For Framework-Specific Best Practices

For deeper, hand-written framework guidance beyond a single finding's fix, see our Laravel, Node/Express, and security headers guides. See our AI assistant documentation for setup details, or create a free account to see AI-generated remediation on your own scan.