// methodology

How the website assessment works

NeoShield assesses the public security configuration of a website you are authorized to check. This page describes exactly what it looks at, how results are scored and verified, and where its limits are.

1. Authorization comes first

You confirm that you own the website or have permission to assess it before every scan, and again when you create a schedule. Scheduled monitoring also needs proof of domain control: a DNS TXT record or a file on the website, re-checked weekly.

2. What is checked

HTTPS availability, HTTP to HTTPS redirects, and the TLS certificate (validity, expiry, hostname).
Security headers: Strict-Transport-Security, Content-Security-Policy, frame protection, X-Content-Type-Options, Referrer-Policy and Permissions-Policy.
Cookie flags: Secure, HttpOnly and SameSite.
Server software disclosure in headers and error pages, and a short list of commonly exposed files and paths.
Email authentication records (SPF, DMARC, optional DKIM selectors you provide), CAA and security.txt.
Deep Scan on paid plans adds checks such as third-party script integrity, detected software versions, HTTP methods and directory listings, still without exploitation.

3. How requests are made

The scanner sends a small number of ordinary GET and HEAD requests, similar to a visitor opening a few pages, and reads public DNS records. Deep Scan also sends one OPTIONS request to see which HTTP methods the server advertises. Only ports 80 and 443 are used. Private, internal, link-local, cloud-metadata and reserved addresses are blocked, including after redirects and DNS resolution.

4. Severity, score and coverage

Each check has a fixed severity (critical, high, medium, low or informational) based on what the weakness allows. Only confirmed open findings reduce the score; informational and review items do not. Coverage and confidence are reported separately, and the grade is capped when some checks could not run, so a partial scan cannot earn a top grade.

The score summarises the configuration that was checked. It is not a security rating, a certification or a guarantee.

How findings are prioritized

Open findings are listed worst first and given a fix priority from their severity: critical is P0, high P1, medium P2, low P3 and informational P4. Within the same severity, findings that affect every visitor (HTTPS, HSTS) come before those that need another weakness to matter (CSP, Referrer-Policy). Severity reflects what the weakness allows on a typical public website; it does not know the business value of a particular site, so adjust the order for your client.

5. Remediation guidance

Findings include why they matter and configuration examples for Nginx, Apache HTTP Server, Microsoft IIS, Cloudflare, WordPress and AWS CloudFront, shown only where they apply. Examples are starting points: test them in staging first. Remediation guidance by platform

6. Fix verification and monitoring

Verify Fix rescans the same website and records each finding as resolved, partially resolved, still present or unable to verify. A finding is marked resolved only when a scan confirms it, and it reopens automatically if a later scan finds it again. Scheduled scans compare each run with the previous one and mark findings as new, improved, regressed or resolved. How verification works

7. AI assistance

Optional AI-assisted prioritisation summarises findings in plain language. It only receives the target hostname, scores and finding text, never your email or IP address. AI output can be wrong: you review it before acting. NeoShield does not manually review each report.

8. What is not checked

No exploitation, login, brute force, fuzzing or load testing.
Authenticated areas and application logic are not assessed.
Source code, plugins and server internals are not inspected.
It is not a penetration test, an audit or a compliance certification.
A clean result does not mean a website is free of vulnerabilities.

9. Standards and references

Each check is based on published guidance, and reports cite the matching CWE, RFC or NIST references next to the finding. The main sources:

Standards and references used by the assessment
Source	What it is used for
OWASP Secure Headers Project	Which HTTP response headers to expect and their recommended values.
Mozilla Web Security Guidelines	Baseline settings for HTTPS, HSTS, CSP, cookies, framing and Referrer-Policy.
NIST Cybersecurity Framework 2.0	Findings concern platform and data security under the Protect function, and monitoring supports Detect. NeoShield does not assess CSF conformance.
CIS Critical Security Controls v8	Secure configuration (Control 4), encryption in transit (Safeguard 3.10) and email protections including DMARC (Control 9). NeoShield checks a few public signals, not the controls.
RFC 6797: HTTP Strict Transport Security	How the HSTS header and its max-age and includeSubDomains directives work.
RFC 9116: security.txt	Format and location of a website’s security contact file.
RFC 7208: SPF	SPF record syntax and the 10-DNS-lookup limit.
RFC 7489: DMARC	DMARC record syntax, policies and reporting.

These references describe where a check comes from. They do not mean that NeoShield, or a website it assesses, is certified against, compliant with or endorsed by any of these organisations or standards. NeoShield holds no SOC 2 or ISO/IEC 27001 certification.

10. Findings explained for developers and for clients

Every report has to work for two readers: the developer who makes the change and the client who approves and pays for it. These are the most common findings, explained both ways.

HTTP Strict Transport Security (HSTS) Severity when missing: High

For the developer: The Strict-Transport-Security response header tells browsers to use HTTPS only for this host for max-age seconds. Without it, the first request a visitor makes over plain HTTP can be intercepted or downgraded before the redirect to HTTPS. Set it on HTTPS responses, start with a short max-age, then raise it to at least six months; add includeSubDomains only after every subdomain works over HTTPS.
For the client: Browsers are not told to always use the secure version of the website. On public Wi-Fi, a visitor could be sent to an insecure copy of a page without noticing. The fix is a one-line server setting.

References: RFC 6797 · OWASP Secure Headers · Mozilla Web Security Guidelines

Content-Security-Policy (CSP) Severity when missing: Medium

For the developer: CSP lists the sources a page may load scripts, styles, frames and other content from. Without an enforced policy, injected script (for example through a vulnerable plugin) runs with no browser-side limit. Start in Content-Security-Policy-Report-Only, collect violations, then enforce. A missing CSP does not prove the site is vulnerable to cross-site scripting; it is a second line of defence.
For the client: The website does not tell browsers which code it is allowed to run. If an attacker ever manages to slip code onto a page, nothing stops it from running in visitors’ browsers. Adding the policy takes testing, because a strict policy can break parts of the site.

References: OWASP Secure Headers · Mozilla Web Security Guidelines · CWE-693

Clickjacking protection Severity when missing: Medium

For the developer: Neither CSP frame-ancestors nor X-Frame-Options was observed, so any site can load these pages in an iframe. An attacker can overlay the frame and trick a signed-in visitor into clicking a real button. Set frame-ancestors 'self' in CSP (preferred) or X-Frame-Options: SAMEORIGIN.
For the client: Another website can show this website hidden inside its own page and trick people into clicking buttons they cannot see, such as “confirm” or “delete”. One server setting stops it.

References: OWASP Secure Headers · Mozilla Web Security Guidelines · CWE-1021

Cookie security flags Severity when missing: Medium

For the developer: Cookies that look like sessions were set without Secure (sent over plain HTTP), HttpOnly (readable by JavaScript) or SameSite (sent on cross-site requests). Set all three on session and authentication cookies. Cookies that do not look sensitive are reported as low-severity items for review, because the scanner cannot see what they are used for.
For the client: The website’s sign-in cookies are missing standard protections, which makes it easier to steal a logged-in session or misuse it from another website. The change is a configuration setting in the site or its platform.

References: OWASP Secure Headers · Mozilla Web Security Guidelines · CWE-614 · CWE-1004

Referrer-Policy Severity when missing: Low

For the developer: No explicit Referrer-Policy was observed. Current major browsers default to strict-origin-when-cross-origin, but older and embedded browsers may still send the full URL, which can contain tokens or search terms, to other sites. An explicit policy makes the behaviour the same everywhere. Set strict-origin-when-cross-origin or no-referrer.
For the client: In some browsers, when visitors follow a link to another website, the full address of the page they were on can be shared with that website. Most current browsers already limit this. It is a low risk, fixed with one server setting.

References: OWASP Secure Headers · Mozilla Web Security Guidelines · CWE-200

SPF (Sender Policy Framework) Severity when missing: Medium

For the developer: No SPF TXT record was found for the domain, so receiving mail servers cannot check which servers may send mail for it. Publish one record listing every legitimate sender (mail host, newsletter and invoicing services), ending in ~all at first and -all once confirmed. Keep it under the 10-DNS-lookup limit.
For the client: The domain does not say which services are allowed to send its email. That makes it easier for criminals to send convincing fake invoices or password-reset emails that appear to come from the business.

References: RFC 7208 · NIST SP 800-177 · CIS Controls v8 (Control 9)

DMARC Severity when missing: Medium

For the developer: No _dmarc TXT record was found. DMARC tells receivers what to do with mail that fails SPF and DKIM alignment, and where to send reports. Publish v=DMARC1; p=none with a rua address, review the reports, then move to p=quarantine and p=reject once legitimate senders align.
For the client: Email providers have no instructions from the business for handling fake email that uses its name, so each provider decides on its own. Setting this up lets the business see who sends email in its name and, over time, have fakes blocked.

References: RFC 7489 · NIST SP 800-177 · CIS Controls v8 (Safeguard 9.5)

Questions

Is this a penetration test?

No. It is a passive configuration assessment. It does not exploit, log in, brute-force or fuzz, and it does not test application logic or authenticated areas.

Are findings reviewed by a person at NeoShield?

No. Findings come from automated checks, and optional AI text summarises them. You review the evidence before acting or sending a report to a client.

Does a high score mean the website is secure?

No. The score summarises the public configuration that was checked. A clean result does not show that a website is free of vulnerabilities.

View the Complete Sample Report Scan One Authorized Website Free