PHP Site AuditMethodology
What an external PHP website assessment checks
PHP Site Audit reviews a bounded sample of public HTTP and TLS responses: up to 100 unique same-host HTML pages, subject to a shared 140-request budget and 90-second scan budget. The report lists the pages and checks actually completed. It can observe reachability, response headers, cookie attributes, and technology clues, but it does not log in, inspect server files or PHP packages, or guarantee that the website is secure.
A bounded view from outside
A public request can show whether a sampled hostname responds, whether an HTTPS certificate validates, which response headers appear, and whether the returned HTML contains clues such as a CMS asset path. These are observations from the chosen path and timestamp. A redirect, geographic CDN route, temporary outage, or host-level access rule may affect what the check can see.
If PHP is not named in a response, the application may still use PHP behind the web server. If a response contains a PHP banner, that does not reveal every runtime serving the domain or confirm a package's patch level.
PHP Site Audit begins at the submitted website and uses public same-host links plus robots.txt and same-host sitemap files as discovery hints. It attempts up to 100 unique public same-host HTML pages, with a shared cap of 140 actual HTTP requests across page fetches, redirects, and discovery and a 90-second scan budget. The report shows which paths were checked; blocked sites, sparse links, or exhausted limits can reduce coverage. This is a bounded sample, not a complete crawl.
Questions this check cannot answer
An unauthenticated external review generally cannot inspect the installed PHP package, server configuration, codebase, database, private endpoints, user roles, or logs. It cannot determine whether a vendor backport is installed unless the provider supplies evidence. It also cannot confirm that an attack occurred or did not occur.
For PHP2Shell, the PHP project says the fixes apply to PHP runtime components and recommends updating. Contact the hosting provider or system owner for package and restart evidence; do not infer patch state from application updates or a response header.
How to use the findings
Treat each result as a prompt for the right owner. Ask the host about runtime versions and TLS, the developer about application behavior and session configuration, and the security team about broader testing or incident evidence. A full penetration test or source review should be scoped separately when the business needs those answers.
A trustworthy report names the sample, evidence, uncertainty, and next step. It does not turn a small set of public signals into an all-clear or a claim of comprehensive testing.
Compare the report's sampled paths with the routes that matter to the business. A site with login-only pages, a separate checkout host or region-specific origins may need additional authorized testing to answer questions outside the public sample.
Common questions
Will the assessment identify the installed PHP package?
No. It samples public responses and does not inspect server files, package databases or vendor backports.
What does the score summarize?
Only the applicable completed external hygiene checks; it is not a compromise probability, PHP patch score or certification.
How many pages does PHP Site Audit check?
It attempts up to 100 unique public same-host HTML pages, subject to a shared 140-request limit and 90-second scan budget. Your report lists the paths actually checked, which may be fewer.