A failing security scan is a prioritized action list, not a verdict. Every finding in a scan report has a concrete fix — the most common ones are single-line configuration changes or framework settings that take minutes to implement. This guide covers the most common security scan findings in order of impact, with exact remediation steps for each one.

Fix 1: Missing HSTS (Highest Impact Per Effort)

Missing HTTP Strict Transport Security is consistently one of the most common High-severity findings and one of the fastest to fix. HSTS instructs browsers to always use HTTPS for your domain, preventing SSL stripping attacks where an attacker downgrades your connection to HTTP.

Add this header to all HTTPS responses:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Nginx — add inside your server block:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache — add inside your HTTPS VirtualHost:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Node.js/Express — using the helmet package: app.use(helmet.hsts({ maxAge: 31536000, includeSubDomains: true }));

Python/Flask — using flask-talisman: Talisman(app, strict_transport_security=True)

After deploying, run a re-scan. HSTS findings resolve immediately once the header is present on HTTPS responses, and your Risk Score improves noticeably because HSTS is a weighted High finding.

Fix 2: Missing X-Frame-Options

A missing X-Frame-Options header allows clickjacking — embedding your page in a hidden iframe on a malicious site to trick users into clicking invisible buttons. The fix is one header added to all responses.

X-Frame-Options: SAMEORIGIN

Nginx: add_header X-Frame-Options "SAMEORIGIN" always;

Apache: Header always set X-Frame-Options "SAMEORIGIN"

Note: If you already have a Content-Security-Policy with a frame-ancestors directive, modern browsers will honor that over X-Frame-Options. Either approach resolves the finding — but adding both provides the widest browser compatibility.

Fix 3: Missing X-Content-Type-Options

This is the simplest header on the list. Without it, browsers may "sniff" the content type of responses and execute uploaded content — such as images — as scripts. One line eliminates the entire attack surface.

X-Content-Type-Options: nosniff

Nginx: add_header X-Content-Type-Options "nosniff" always;

Apache: Header always set X-Content-Type-Options "nosniff"

Fix 4: Missing Content-Security-Policy

Content-Security-Policy is the most complex header to configure correctly because it must enumerate all the domains your application loads resources from. Avoid breaking your site by starting in report-only mode:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'

Open your browser's developer console and review CSP violations as you browse the site. Adjust the policy to allow all legitimate sources, then switch to enforcement by changing the header name to Content-Security-Policy. Even a basic policy immediately limits the damage of any XSS vulnerability by preventing injection of external scripts.

Fix 5: Insecure Cookies (Missing Secure and HttpOnly Flags)

Cookies without the Secure flag can be transmitted over HTTP connections. Cookies without the HttpOnly flag can be read by JavaScript, enabling session theft via any XSS vulnerability. Both flags are required on every authentication and session cookie.

Python/Flask: Set SESSION_COOKIE_SECURE = True and SESSION_COOKIE_HTTPONLY = True in your application config.

PHP: In php.ini set session.cookie_secure = 1 and session.cookie_httponly = 1. Or call session_set_cookie_params(['secure' => true, 'httponly' => true, 'samesite' => 'Strict']); before session_start().

Node.js/Express: Pass { secure: true, httpOnly: true, sameSite: 'strict' } to your session middleware cookie options.

Django: Set SESSION_COOKIE_SECURE = True, SESSION_COOKIE_HTTPONLY = True, and SESSION_COOKIE_SAMESITE = 'Strict' in settings.py.

Also add SameSite=Strict to defend against CSRF attacks, unless your application serves cross-site embedded functionality that requires cross-site cookie access.

Fix 6: HTTP Not Redirecting to HTTPS

If your site returns content over HTTP without redirecting to HTTPS, all HTTP traffic is unencrypted. Configure the redirect at the server level — not the application level — so it applies before any application code runs and covers all request types including static assets.

Nginx — add a dedicated HTTP server block:

server {
        listen 80;
        server_name yourdomain.com www.yourdomain.com;
        return 301 https://$host$request_uri;
    }

Apache — add to your HTTP VirtualHost:

RewriteEngine On
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Verify the redirect is a 301 (permanent), not 302 (temporary). A 301 is required for browsers to cache the redirect, for HSTS to function correctly, and for search engines to transfer SEO signals to the HTTPS URL.

Fix 7: Exposed Server Version in Response Headers

A Server: Apache/2.4.51 or Server: nginx/1.21.0 header immediately tells attackers which known CVEs apply to your server. One configuration change removes the version number.

Nginx — add to the http {} block in nginx.conf:

server_tokens off;

Apache — add to your main Apache configuration:

ServerTokens Prod
    ServerSignature Off

After this change, the Server header returns only nginx or Apache without a version number. Also check for the X-Powered-By header — remove it with Header unset X-Powered-By in Apache or proxy_hide_header X-Powered-By; in Nginx.

Fix 8: Open Directory Listing

If your scan found accessible directory listings — the web server returning a browsable file index for a directory — disable it at the server level immediately. Directory listings expose backup files, configuration files, and any other files stored in that directory to any visitor.

Nginx: Confirm autoindex is absent or explicitly set to off in your server and location blocks. Add autoindex off; to any location block where it might have been enabled.

Apache: Add Options -Indexes to your VirtualHost configuration or to an .htaccess file in the affected directory. This removes the Indexes option that enables browser-visible directory listings.

How Shieldome Helps You Verify Every Fix

After implementing fixes, run a Shieldome re-scan to verify each change is working in production. Shieldome checks headers and behavior in real HTTP responses — not just configuration files — so a re-scan confirms that your change is actually deployed and effective, not merely present in a config that may not have been reloaded. Most header fixes result in an immediate, visible Risk Score improvement after re-scanning.

When a Shieldome scan returns a low score, findings are sorted by severity so the highest-impact fixes are always at the top. The most common fixable findings in order of score impact are: (1) missing HSTS, (2) missing X-Frame-Options or CSP, (3) insecure cookie flags, (4) HTTP not redirecting to HTTPS, and (5) exposed server version. Addressing these five categories alone typically raises a failing score by 30 to 50 points, depending on the starting state.

For teams deploying frequently, Shieldome's API can be integrated into CI/CD pipelines to catch security regressions before they reach production — treating a failing security scan the same way a failing test suite is treated: a deployment blocker.

Frequently Asked Questions

In what order should I fix findings from a security scan?

Always fix by severity first: Critical, then High, then Medium, then Low. Within each severity level, prioritize the quickest fixes first — a one-line header change that resolves a High finding should be done before a complex code refactor resolving a different High finding of the same weight. Quick wins reduce active risk while you work on more complex issues.

How long does it take to fix the most common scan findings?

The five most common findings — missing HSTS, X-Frame-Options, X-Content-Type-Options, insecure cookies, and server version disclosure — can typically all be fixed in under two hours by a developer or sysadmin familiar with their server configuration. More complex findings like SQL injection or broken access control require code changes and testing that may take days to address properly and safely.

Will adding security headers break my website?

Adding HSTS, X-Frame-Options, and X-Content-Type-Options does not break functionality — they restrict browser behaviors rather than changing content delivery. Content-Security-Policy is the exception: a strict CSP can break pages that load resources from domains not listed in the policy. Always test CSP in report-only mode before switching to enforcement mode, and review browser console violations on every page of your application before enforcing.

Do I need a developer or a sysadmin to fix scan findings?

For header and server configuration findings, a sysadmin or DevOps engineer can implement fixes without application code changes. For application-level findings — injection vulnerabilities, broken access control, insecure deserialization — a developer is needed to fix the underlying logic. Most small business and mid-market websites will find that the majority of their scan findings are configuration-level fixes that do not require deep application development knowledge.

What if my Risk Score goes up after fixing, but does not reach 100?

A score of 100 indicates no significant findings — it is achievable but not always the practical goal. A score above 85 with no Critical or High findings represents a well-configured application. Remaining findings at that score level are typically Low or Info severity — best-practice improvements rather than active security risks. Focus on eliminating Critical and High findings; the score reflects that directly.

How do I prevent findings from reappearing after new deployments?

Add security scanning to your CI/CD pipeline. Run a Shieldome scan as part of your deployment process using the Shieldome API. Configure the pipeline to fail if Critical or High findings are detected — the same way a failed unit test blocks a merge. This turns security from a periodic audit into a continuous deployment gate, preventing regressions before they reach users.

Shieldome makes it easy to find, prioritize, and verify security fixes. Run a scan, fix what Shieldome finds, then re-scan to confirm — each fix is reflected immediately in your Risk Score. Create a free account and start improving your security posture today.