What a website configuration scan can—and cannot—tell you

A report says your homepage did not return a Content Security Policy (CSP) header. Does that mean someone can inject code into your application? Not by itself. It identifies a configuration question; it does not establish an injection vulnerability. To use the finding well, separate what the inspection received, why that setting might matter, and what nobody has checked.

Here is a synthetic example. A builder has a website at demo.example, with a homepage and a signed-in account area. An inspection receives one HTML response from the homepage. It does not enter the account area. The response has no enforced CSP header. That evidence is enough to identify an absent response header, but not to describe every policy applied to the page.

Read the evidence one row at a time

The table below is teaching material, not a SecurityFuse report export. It deliberately includes an unanswered question alongside the observation.

Notice the difference between the first and last rows. The first contains an observation about something inspected. The last records a boundary. It has no pass or failure result for account access. Treating both as the same kind of result would hide the question that still needs an answer.

The resource matters too. A homepage response is not a statement about every page the application can produce. If your repair decision concerns the account area, evidence from the homepage cannot do that work for you. Write down the resource the observation concerns before deciding where to make a change.

Separate the setting from a possible attack

HTTP carries messages and fields. HTTP Semantics, sections 5 and 6 supplies the protocol background for reading those fields. A response observation needs a narrower interpretation than a claim about the application's internal behavior.

CSP can matter because it controls which resources a browser may load for a document. MDN's Content Security Policy guide explains that mechanism as defense in depth; it does not replace input sanitization. That helps explain why a missing policy deserves attention without turning its absence into proof of an attack.

For the example, keep three sentences distinct: “The response did not include the header” describes evidence. “A suitable policy can restrict resource loading” explains the mechanism. “This application contains an exploitable injection flaw” would require different evidence. The third sentence does not follow from the other two.

That distinction changes the task you give a coding assistant. Asking it to remove an injection flaw assumes one was found. Asking it to investigate a missing CSP header preserves the actual starting point. A narrow finding can still lead to useful work without being promoted into a stronger diagnosis.

Ask what the inspection left out

Before deciding that an empty part of a report is reassuring, ask whether that part of the application was inspected. In our example, the account question remains open even if the homepage produces no other findings. There was no attempt to compare what two different users could access.

Keep “not inspected” separate from “inspected without a finding.” Also ask whether an attempted check completed. If an inspection could not obtain the response it needed, a blank result does not supply the missing observation. You need the reason for the gap before deciding what to do next.

This is particularly useful when your application has several delivery paths. A public page, a signed-in route and a background task can raise different questions. List the question you need answered, then look for evidence relevant to it. Do not let one useful configuration observation stand in for those separate reviews.

Choose the next question, not a larger verdict

For the missing-CSP example, the next question is concrete: where are response headers configured, and what policy fits the resources this page needs? A security header finding is a starting point develops that decision using an annotated response and a bounded change request.

If you later change the configuration, interpreting the new observation is a separate task. From a repair statement to a comparable recheck explains why an edit and a later response are different evidence. You do not need to settle that later question to read today's scope correctly.

SecurityFuse's public sample comes from our own test site and keeps assessed and unassessed areas visible. SecurityFuse is available by invitation. Hosted website scanning is not currently enabled. The sample can help you read a bounded result; it is not an entry point for submitting a website. Start with the response, keep the unanswered questions visible, and let that boundary determine the next investigation.