The difficult moment is rarely discovering that a scanner found something. It is deciding whether that something can expose customer data, interrupt sales or wait until the next maintenance window. A report with twenty red labels and no reproducible evidence creates work without helping you make that decision.
A website security audit examines a defined target from a particular network position at a particular time. Sitelemetry combines selected security modules into findings, evidence and a checks list. Read those together: a completed job means the job finished, not that every possible attack was attempted or every account workflow was examined.
What this audit covers
What can be measured
- Depending on the selected modules: DNS and email policy, TLS, HTTP headers, technology signals, public exposure and API surface.
- Where the plan and profile permit: selected TCP ports, authentication surface, supply-chain signals and additional security engines.
- The checks list records supported successful checks and incomplete observations alongside findings.
What it cannot prove
- An external scan cannot prove all authorization rules, private endpoints or business logic are safe.
- Timeouts, filtering, authentication requirements and unavailable engines reduce coverage; they are not clean passes.
- A technology fingerprint or open connection does not by itself prove an exploitable vulnerability.
Verify ownership and authorization before scanning. The plan, chosen profile, explicitly selected modules and engine availability determine coverage. Check the actual report scope; selecting a full audit does not bypass these conditions.
Start with the evidence, not the score
For each finding, look for the affected hostname or URL, observation time, module, response or connection evidence, confidence and proposed fix. A missing header observed in a real HTTP response is different from a request that never completed. If the TLS handshake fails, header coverage is unknown; inventing five missing-header findings would exaggerate the result.
Preserve the smallest useful evidence in your internal ticket. For an exposed secret, record its location and a redacted identifier rather than copying the credential into a shared issue. A technology version match is a lead for investigation: compare the deployed version and vendor advisory before calling it a confirmed compromise.
Use severity to order work, then add business context
| Observation | Practical priority | Next decision |
|---|---|---|
| A usable credential is publicly exposed | Urgent; potentially critical depending on permissions | Revoke or rotate it and investigate access |
| Expired or untrusted public TLS certificate | High | Restore trusted access and verify renewal |
| Missing browser security policy | Usually medium or low, depending on the control | Review application behavior before enforcing it |
| Technology disclosure or framework identification | Usually low or informational | Confirm relevance and patch status |
| Port 443 accepts connections | Expected service observation | Assess TLS and the application, not the port number alone |
These are triage examples, not a replacement for the finding's evidence. A customer login page deserves different attention from a public static asset. Confidence describes how certain the observation is; severity describes potential consequence. Neither tells you whether exploitation has actually happened.
Open ports and informational alerts need context
A public HTTPS website needs an HTTPS listener. Port 443 being open is not a vulnerability on its own. Port 80 can also be appropriate when it redirects to HTTPS; verify the actual behavior. Administrative, database and legacy transfer services need a clear owner and a reason for public exposure. A successful TCP connection proves reachability, not anonymous access or a particular software version.
Keep one remediation task per underlying exposure when a generic port observation and a service-specific finding describe the same issue. A timeout is not proof that a port is closed. Likewise, ZAP's Modern Web Application alert is informational: it suggests a crawling strategy, not a defect requiring a security patch.
Repair the cause without breaking legitimate traffic
- Contain verified exposure. Remove unintended public access, rotate affected credentials and inspect relevant logs. Removing a file alone does not revoke a leaked key.
- Fix the owning layer. TLS may terminate at a CDN; headers may be added by a reverse proxy; a listening service may belong to a separate host. Change the layer that produces the observed response.
- Stage behavior-changing policies. Test CSP reporting, login redirects, embedded checkout and required integrations before enforcement.
- Reduce unnecessary access. Limit administrative services to the network paths their operators need while preserving a tested recovery route.
Assign a responsible person, target date and acceptance evidence to each task. Do not disable every service merely to improve a score. The goal is a smaller justified attack surface with working customer journeys.
Make the retest comparable
Repeat the relevant check with the same hostname, scheme, profile and modules. Record both reports and the intervening change. If DNS, a CDN or a cache is involved, confirm that the scan reached the updated service. A higher score after silently disabling a module is not evidence that the weakness was repaired.
- Confirm the original evidence no longer reproduces.
- Check login, signup, payment and embedded content where your change can affect them.
- Review skipped, failed and partial modules, including engine availability.
- Close the ticket with the new observation; retain unresolved limitations separately.
Know when automated evidence needs human testing
Account isolation, privilege escalation through business workflows and authorization between two real users usually require deliberate authenticated test cases. A public scan may identify an authentication surface without validating those rules. Use OWASP's testing guide to plan additional authorized investigation and the HTTP headers guidance when reviewing browser controls.
Schedule a baseline before a significant release and repeat affected checks after infrastructure, authentication or dependency changes. Automated reports support maintenance; they do not grant a compliance certificate, guarantee an attack-free site or replace a scoped penetration test.
Common questions
Does a high security score mean the website is safe?
It means the measured controls produced that score within the reported scope. Review evidence, skipped modules and untested account workflows before making a broader claim.
Should every informational result become a repair ticket?
No. Keep useful inventory observations, but create repair work when there is a relevant weakness or an operational requirement. Expected HTTPS availability is not a defect.
Can I run the same audit through an MCP client?
Supported MCP tools use your account's permissions and plan. Verify the selected scope and completion details; availability of a tool does not mean every module or external engine ran.
Sources & further reading
- OWASP Web Security Testing Guideowasp.org
- ZAP: Modern Web Application informational alertwww.zaproxy.org
- OWASP HTTP headers guidancecheatsheetseries.owasp.org
Written by the Sitelemetry team, checked against the product’s audit scope and linked primary sources. Examples are illustrative unless an observed case is explicitly identified.
