PHP Site AuditAssessment limits
What a public PHP security check can and cannot prove
An external check can observe the responses available to a visitor, such as status codes, TLS certificates, selected headers, cookies, and technology clues. It cannot normally inspect server packages, PHP worker memory, hidden routes, authenticated areas, source code, or logs. A result is bounded evidence about the sampled public surface, not a penetration test or a security certification.
Observations are not the same as server inventory
A visible X-Powered-By value is only a response header. It might be removed or customized, and an intermediary may change it. A WordPress marker in HTML is a clue rather than proof of every installed component. A secure TLS connection proves that the sampled connection passed certificate validation at that moment; it does not prove the application is free of vulnerabilities.
PHP2Shell illustrates the distinction. The relevant vulnerabilities were in the PHP runtime that processed requests. An external HTTP response cannot reveal whether the host installed the exact fixed package, applied a vendor backport, or restarted every serving process. Verify those facts with the hosting provider or platform inventory.
What a scoped external assessment is good for
A bounded check can highlight missing response headers, an HTTP-only path, visible technology disclosure, or common cookie attributes on the response it sampled. These observations can help prioritize questions for a developer or host. They need context: some headers are meaningful only on certain response types, some applications require cross-site cookies, and a missing cookie on the home page says nothing about a separate authenticated workflow.
A useful report gives the evidence, explains which URL or response was examined, and suggests a next step. It should also state what it did not inspect. A scanner that claims to certify a website from a single landing-page response is making a stronger claim than the evidence supports.
When to expand the review
Use server-side package checks for runtime patch state, source review for application logic, authenticated testing for logged-in functionality, and a properly authorized penetration test for broader adversarial coverage. Choose the review based on the question. No single automated result can guarantee security across a changing web application.
Common questions
What does an unknown result mean?
The sampled evidence could not establish the check. It is neither a pass nor a confirmed defect.
Can a clean check prove there is no vulnerability?
No. A public sample cannot inspect server packages, authenticated areas, source code or historical activity.
How should a developer use a finding?
Reproduce the observation, assess its relevance to the application, test a scoped change and verify the response again.