Web Security Scanner
Badrul Amin
Infrastructure & DevOps SpecialistReview a public HTTP or HTTPS endpoint from the InfraStack server and collect visible response evidence for edge posture review. Check HTTPS, HSTS, CSP, frame protection, cookie flags, redirects, disclosure headers, CORS exposure, and public security files. Inspect findings, evidence, and normalized output before exporting notes for remediation tracking or a later comparison pass.
Findings
| # | Category | Control | Status | Evidence | Recommendation | Copy |
|---|
Header Matrix
| # | Category | Header | Value | Copy |
|---|
Transport Summary
| # | Field | Value | Copy |
|---|
Well-Known Files
| # | Path | Status | Note | Copy |
|---|
Cookies
| # | Name | Secure | HttpOnly | SameSite | Issues | Copy |
|---|
Overview
Web Security Scanner is an InfraStack security workspace for checking a public web endpoint from the application server and turning visible response behavior into reviewable findings. OWASP (n.d.) organizes common HTTP security response headers for browser-facing hardening, so this scanner treats headers as review evidence rather than proof of application security.
IETF (2012) standardizes HTTP Strict Transport Security, which is why HSTS appears as a separate HTTPS retention finding.
IETF (2022) defines HTTP semantics for request and response behavior, so server-side header evidence still needs application-context review before remediation is assigned.
It inspects the signals that are exposed at the edge: HTTPS, redirect posture, HSTS, CSP, frame protection, MIME sniffing protection, referrer and permissions policy, disclosure headers, cookie attributes, CORS exposure, and well-known files such as security.txt and robots.txt.
Use the workspace when you need a quick hardening review that can be copied into a ticket, shared as JSON, or exported as a findings table. The result is useful for triage, change validation, baseline checks, and review notes. Treat the result as visible response evidence, not as proof that the application, dependencies, cloud account, or runtime are secure.
| Workspace area | What it gives you | What to review next |
|---|---|---|
| Target | A normalized public HTTP or HTTPS URL checked from the server side. | Confirm you are authorized to review the target and that private targets are out of scope. |
| Request options | HEAD or GET selection, redirect handling, timeout, TLS validation, user-agent profile, and companion probes. | Use GET or a browser-like user agent when the server sends different headers for normal content delivery. |
| Findings | Pass, warning, failure, or informational rows with evidence and remediation hints. | Prioritize transport failures, missing HSTS on HTTPS, weak cookies, and permissive CORS first. |
| Evidence | Header matrix, cookie rows, transport summary, well-known file probes, and JSON output. | Use the raw evidence when assigning remediation work. |
| Exports | PDF, CSV, copied JSON, and downloaded JSON for different review workflows. | Use CSV for triage rows and JSON when the complete scan payload needs to be archived. |
Technical Details
The scanner builds one result payload from the target URL, request options, server response, companion probes, and generated findings. That payload drives the hardening score, tabs, CSV output, copied JSON, and downloaded JSON.
The technical checks stay tied to security-header and protocol sources. OWASP (n.d.) anchors the response-header review scope, IETF (2012) anchors HSTS as an HTTPS retention signal, and IETF (2022) anchors the request and response semantics that make method, redirect, and final URL context matter.
- Confirm the target, final URL, request method, redirect setting, TLS setting, and timestamp.
- Check transport failures before reading warnings or score changes.
- Use GET when HEAD hides application or CDN headers.
- Match user-agent and TLS validation to the review path you need to defend.
- Use CSV for triage rows and JSON for the full scan payload.
- Assign headers, cookies, CORS, transport, and disclosure findings to the layer that owns them.
- The scanner observes public responses; it does not inspect code, auth, dependencies, or private networks.
- A high score is not security proof, and a low score still needs endpoint context.
1. Server-side request model
The primary request runs from the Symfony backend so normal browser CORS restrictions do not block header inspection. The scanner accepts only HTTP and HTTPS URLs, normalizes missing schemes to HTTPS, resolves host addresses, and rejects local or private network targets.
That boundary matters. The tool is intended for public endpoints that you are allowed to review. It is not built for internal host discovery, SSRF testing, authenticated application crawling, or private service enumeration.
2. Request controls
The workspace supports HEAD or GET, redirect following, timeout limits, TLS validation, GET fallback when HEAD returns 405, user-agent profiles, well-known file probes, and HTTP-to-HTTPS upgrade probing. Those controls are synced into the page URL so the same scan setup can be reopened.
HEAD is faster and usually enough for response headers. GET is better when a server, CDN, WAF, reverse proxy, or application layer returns different headers for normal page delivery. Redirect following should stay enabled for most reviews because the final destination is usually the user-facing security boundary.
3. Finding classification
Findings are practical posture checks. Transport failures and missing HTTPS are treated more severely than context-sensitive headers. Missing CSP, frame protection, referrer policy, permissions policy, and disclosure headers are warnings unless the surrounding response makes them more urgent.
The score is a triage aid. It helps compare visible hardening posture between runs, but it is not a compliance score, exploitability rating, or security certification.
4. Header and cookie review
Header checks focus on common browser-facing controls:
- HSTS uses
Strict-Transport-Securityfor HTTPS retention. - CSP uses
Content-Security-Policyfor resource loading boundaries. - Frame protection uses
X-Frame-Optionsorframe-ancestorsfor clickjacking resistance. - MIME protection uses
X-Content-Type-Optionsfor sniffing resistance. - Referrer policy uses
Referrer-Policyfor referrer data exposure. - Permissions policy uses
Permissions-Policyfor browser capability limits. - Disclosure review catches headers that reveal framework, platform, proxy, or runtime details.
Cookie checks look for Secure, HttpOnly, and SameSite attributes when cookies are visible in the response. A response with no cookies is reported separately from a response with weak cookies.
5. CORS and public file probes
CORS checks look for overly broad or risky cross-origin read behavior in visible response headers. A permissive value can be legitimate for a public API, but it should still be reviewed against the expected client origins and credential behavior.
Well-known file probes check public paths such as /.well-known/security.txt, /security.txt, /robots.txt, and related security discovery locations when that option is enabled. These probes help reveal coordination and indexing signals, not vulnerability proof.
6. Visible surface inventory
The result keeps the raw review surface close to the score: returned headers, cookie attributes, final URL, redirect count, HTTP upgrade probe, well-known file rows, and generated timestamps. This helps reviewers move from "the score is low" to "this exact response header or cookie needs work."
7. Scope boundaries
The scanner does not scan source code, dependencies, containers, CI pipelines, cloud accounts, authenticated pages, private networks, exploitability, malware, or runtime agents. It is an edge-observability and hardening review tool, not a penetration test or a full application security platform.
- Public response evidence does not prove authentication, authorization, session design, input validation, or business logic quality.
- Header evidence can be correct on one path and different on another path, method, region, device class, or CDN route.
- Scanner output should become a review queue, not a trophy or a blanket security statement.
8. How to read the result
Start with reachability and final URL. If the request failed, redirected unexpectedly, or landed on a different host, the header findings may describe the wrong surface for your review goal. Then inspect transport results, security headers, cookies, CORS behavior, disclosure headers, and public file probes. That order keeps the review close to the evidence instead of jumping straight to the score.
The score is a triage signal. It is useful for comparing the same endpoint over time or for quickly spotting missing browser-facing controls. It is not a vulnerability severity score, compliance rating, or exploitability measure. A low score deserves investigation. A high score still needs context, especially for authenticated applications, APIs, CDN-fronted sites, redirects, and pages that serve different responses by method, device, region, or user-agent.
9. Evidence discipline
Findings should be handled with their evidence. A missing HSTS finding means the HTTPS response did not include the expected header on this request path. A weak cookie finding means a visible Set-Cookie header missed one of the reviewed attributes. A CORS warning means the observed response advertised a broad or risky cross-origin read behavior. Those are concrete observations, but they still need owner review.
Keep the raw headers and cookie rows close to remediation work. Proxy layers, application frameworks, CDN rules, WAF policies, and platform defaults can all add, remove, or rewrite headers before the response reaches the scanner. The correct fix might belong in application code, an ingress controller, a reverse proxy, a CDN rule, or a hosting platform setting.
10. Request option boundaries
HEAD and GET can produce different answers. Some sites return minimal headers to HEAD, block HEAD entirely, or route GET through a different application path. GET fallback helps when HEAD returns 405, but it does not prove every page or route has the same posture. Redirect following is usually helpful, but it can hide where a policy is actually set. TLS validation should stay enabled for normal review so certificate problems remain visible.
User-agent selection also matters. A security appliance, CDN, or application may send different headers to a browser-like client than to a generic scanner. That does not make one result fake; it means the edge behavior varies by request profile. When a finding matters, repeat the scan with the profile that matches real traffic and keep that context in the handoff notes.
11. Public target and authorization rules
The backend rejects local and private network targets because this tool is not for internal discovery or SSRF-style probing. Use it only for public endpoints you are authorized to review. Authorization is not a form field, but it is still required. A public URL can belong to another organization, customer, vendor, or shared platform.
Well-known file probes are intentionally narrow. They can reveal whether security contact files, robots rules, or related public paths exist, but they do not crawl the site. They should be read as coordination and indexing signals, not proof of security maturity.
12. Export and remediation workflow
CSV is useful for turning findings into triage rows. JSON is better when the full scan context, options, evidence, and generated findings need to stay together. Neither export proves that a target is secure. They preserve what this scanner observed during one request sequence.
For remediation, group findings by owner. Transport and certificate issues may belong to platform or edge teams. Header policy may belong to application, ingress, CDN, or security engineering. Cookie flags may belong to the application framework or session layer. CORS may require API and frontend ownership together. Disclosure headers may be removed at several layers. Clear ownership beats a long list of undifferentiated warnings.
13. Practical review checklist
Before sharing results, use the scanner output like a compact review file:
- Intent: Confirm the target URL, final URL, endpoint type, owner, and reason for the scan.
- Request: Confirm the method, redirect setting, user-agent profile, TLS validation setting, companion probes, and timestamp.
- Evidence: Review failures and warnings against the raw headers, cookies, transport rows, CORS fields, and public-file probes.
- Assignment: Map each real issue to the layer that can fix it, such as app, ingress, CDN, WAF, platform, or DNS owner.
- Closure: Keep before-and-after evidence with the ticket, not just a changed score.
The final question is whether the finding can be reproduced and assigned. If yes, export the evidence and create the remediation item with the exact header, cookie, CORS, or transport condition. If no, rerun with clearer options or collect a browser trace. The scanner is most useful when it turns public edge behavior into specific next work, not when it becomes a badge.
14. Change tracking
Use repeated scans carefully. A changed score can mean the site improved, regressed, redirected somewhere else, changed CDN behavior, served a different response to the selected method, or exposed a temporary deployment state. Compare final URL, status code, headers, cookies, and request options before celebrating or panicking.
When a remediation is applied, keep before-and-after evidence. The useful proof is not "the score went up"; it is the exact header added, cookie flag changed, redirect fixed, CORS value narrowed, TLS issue resolved, or disclosure removed. That evidence helps the owner verify the fix and helps the next reviewer understand why the finding closed.
15. Human review boundary
Public edge checks are only one layer of web security. They do not answer whether authentication is correct, authorization is enforced, input validation is strong, secrets are protected, dependencies are patched, or business logic is safe. Use this scanner to improve visible HTTP posture, then hand deeper questions to the right application, platform, or security process.
Final review should end with an owner, a finding, and evidence path. If the issue is real, say who fixes it, where the control belongs, and what response will prove closure. If the result is noisy, say which option should be rerun. If it is accepted risk, record who accepted it, why, and when it should be revisited. That discipline keeps scanner output useful after the initial score loses novelty during remediation review and follow up work later on too.
| Review layer | What the scanner observes | Where the human still decides |
|---|---|---|
| Reachability | Final URL, status, redirects, timeout behavior, TLS validation behavior, and certificate handling. | Whether this is the intended public surface and whether redirects land on the right owner. |
| Browser guardrails | HSTS, CSP, frame protection, MIME sniffing protection, referrer policy, and permissions policy. | Whether the observed policy fits the endpoint type instead of merely looking tidy in a table. |
| Session hints | Visible Set-Cookie attributes such as Secure, HttpOnly, and SameSite. |
Whether the cookie belongs to a sensitive flow and whether framework defaults are doing the right job. |
| Public coordination | security.txt, robots.txt, and related public discovery paths when probes are enabled. |
Whether the file content is current, owned, and useful to the team that receives reports. |
| Export state | CSV finding rows and JSON scan payloads generated from the same result model. | Whether the handoff includes ownership, evidence path, accepted-risk notes, and retest criteria. |
Example Scan Inputs
Use these examples as scan briefs. Set the matching target and options, run the scan, then review the findings and evidence tabs before exporting.
Target: https://example.com
Method: HEAD
Follow redirects: on
Validate TLS: on
Check well-known files: on
Probe HTTP upgrade path: onShow scan use Hide scan use
Target: https://www.example.com
Method: GET
User-Agent profile: Desktop browser
Follow redirects: on
Validate TLS: on
Fallback GET on 405: onShow scan use Hide scan use
Target: http://example.com
Method: HEAD
Follow redirects: on
Validate TLS: on
Probe HTTP upgrade path: on
Check well-known files: offShow scan use Hide scan use
Target: https://app.example.com
Method: GET
User-Agent profile: Desktop browser
Follow redirects: on
Validate TLS: on
Check well-known files: off
Probe HTTP upgrade path: onShow scan use Hide scan use
Interpretation Notes
Use the result as a structured review queue. Start with the status chips and score card, then move into the findings table and raw evidence tabs before assigning remediation work.
| Signal | How to read it | Practical next step |
|---|---|---|
| Failure | A visible edge control is missing, broken, or unsafe for a common public-web baseline. | Confirm the evidence, then create a remediation ticket with the exact header, cookie, or transport condition. |
| Warning | The response may be acceptable in some contexts, but it deserves review. | Check whether the target is a marketing page, API, redirect endpoint, file host, or application shell before deciding severity. |
| Pass | The expected visible signal was present for this request path. | Keep the evidence with the review, especially after proxy, CDN, WAF, or deployment changes. |
| Info | The scanner observed a useful fact that may not be good or bad by itself. | Use it as context when interpreting redirects, final URL, request method, and public files. |
Results can change between runs if the target uses geo routing, CDN cache variation, device-specific responses, per-path header policies, load-balanced origins, deployment rollouts, or bot detection. When accuracy matters, rerun with the same options and compare JSON outputs before treating a difference as a regression.
How To Use
Use this workflow to move from a target URL to evidence-backed review notes. Keep the scan focused, then use the raw evidence before assigning remediation work.
1. Enter a public target
Enter the HTTP or HTTPS endpoint you are authorized to review, then confirm the normalized target before scanning.
2. Set request and probe options
Choose the request method, redirect handling, timeout, TLS validation, user-agent profile, fallback behavior, and companion probes that match the evidence you need.
3. Run the scan
Run the scan to collect server-side response evidence, findings, score context, header rows, cookie rows, transport rows, and public-file probe results.
4. Review findings and evidence
Start with failures and warnings, then inspect the raw evidence tables so each remediation item keeps the exact observed header, cookie, CORS, transport, or probe condition.
5. Export or restore scan results
Use Export PDF for review notes, Download CSV for triage rows, and Copy JSON, Download JSON, or Import JSON when the full scan result should be preserved.
Export Notes
The workspace exports scan evidence through several paths, but they do not preserve the same information.
Export PDF
Use Export PDF when the current scan result needs a printable review artifact for a ticket, audit note, change record, or meeting handoff.
PDF is best for human review. It does not preserve editable scanner state.
Download CSV
Use Download CSV when findings need spreadsheet triage, ticket import, remediation tracking, or repeated comparison.
CSV focuses on finding rows. It does not preserve every raw header, cookie, transport, or well-known file detail.
Copy JSON / Download JSON
Use Copy JSON or Download JSON when you want to preserve the full scan payload.
- Query options
- Summary counts
- Finding rows
- Header, transport, cookie, and well-known file evidence
- Generation time
JSON is the restore format for this scanner payload.
Import JSON
Use Import JSON to reopen a saved scan payload and rebuild the controls, summary, finding tables, evidence views, and JSON output.
FAQ
Use these answers to keep scan output in the right lane: public edge evidence, not a full security verdict.
Is this comparable to a full application security platform?
Why does the scan run from the server?
Why is a missing header not always a failure?
Why can results change between scans?
What should I do with a permissive CORS finding?
Can it scan authenticated or private applications?
Acronyms
| Acronym | Meaning | Why it matters in this tool |
|---|---|---|
| HSTS | HTTP Strict Transport Security | Confirms browsers are told to keep using HTTPS after a secure response. |
| CSP | Content Security Policy | Limits which resources a page can load or execute. |
| CORS | Cross-Origin Resource Sharing | Controls which browser origins can read responses across sites. |
| TLS | Transport Layer Security | Protects HTTPS connections and certificate validation checks. |
| WAF | Web Application Firewall | May alter headers, redirects, status codes, and bot handling before the application responds. |
| CDN | Content Delivery Network | May serve cached responses or apply edge header policies that differ from the origin. |
| XFO | X-Frame-Options | Legacy frame protection header checked alongside CSP frame controls. |
| JSON | JavaScript Object Notation | Used for the full structured scan result export. |
References
These sources support the in-text citations used in this tool page.
| Source type | In-text citation | Reference |
|---|---|---|
| Security cheat sheet | (OWASP, n.d.) | OWASP. (n.d.). HTTP Security Response Headers Cheat Sheet. Retrieved May 13, 2026, from https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html |
| RFC | (IETF, 2012) | IETF. (2012). RFC 6797: HTTP Strict Transport Security (HSTS). https://www.rfc-editor.org/rfc/rfc6797 |
| RFC | (IETF, 2022) | IETF. (2022). RFC 9110: HTTP Semantics. https://www.rfc-editor.org/rfc/rfc9110 |