Website scan authorization: attestation, ownership and limits

Separate authority to request a scan, HTTPS file proof and the limits of Quick and Deep before you collect evidence.

Can you authorize this inspection?

You can edit an application's code and publish a file to its website. Does that mean you can authorize any security scan against the hosting account? No. Control of a file is a technical fact. Authority to commission an inspection depends on the permissions and scope you actually have.

Use this synthetic example: a builder maintains https://demo.example/ for a business owner. The builder can deploy the application, while a hosting provider operates the shared infrastructure. No real site or customer is represented.

Question	Evidence or decision needed	What it does not establish
May the builder request the assessment?	Permission from the responsible party covering the proposed target and work, with applicable provider restrictions checked	Authority over every service on the hosting account
Can the builder publish the verification file?	The exact challenge file is returned from the target origin and passes verification	Every contractual or organizational permission
What may the scan inspect?	The selected profile and the scanner's stated boundaries	Permission to add another hostname, account session or testing method
May a later recheck run?	Authority for the new execution and, for Deep, current ownership proof	Unlimited permission inherited from an earlier report

The rows are separate questions. Passing the file check cannot answer the first row for you, and accepting responsibility cannot make an unsupported scan method available.

Attestation is a responsibility

SecurityFuse's hosted website scanning is available to invited users who sign in and have active access. Before starting a scan, you must accept the current Terms and Acceptable Use Policy, confirm that you own the target or have permission covering the assessment, and have scan allowance available.

Quick requires that authorization attestation. Deep requires it too, plus current verified ownership proof. The checkbox records your confirmation; it is not a substitute for resolving an unclear permission before sending traffic.

In the example, the builder should establish what the business owner permits and whether the hosting provider imposes restrictions. If those facts are unclear, pause. Public reachability alone does not supply authority. Read the Acceptable Use Policy and Terms for the actual service conditions; this article is a practical explanation, not legal advice or a separate permission grant.

File proof establishes a narrower fact

For Deep, choose Create HTTPS file challenge. Publish the exact token bytes, with no trailing newline, at /.well-known/securityfuse-verification.txt on the target origin. Then choose Verify published file. Creating a challenge does not contact the website; verifying the published file does.

The proof expires after one hour. Deep scans and Deep rechecks need a current verified proof. A file that was valid earlier is not an indefinite authorization to inspect the target. File verification also does not follow redirects, so placing the token behind a redirect is not the same as serving it at the required location.

Our builder might be able to complete those steps while still lacking permission to assess another service run by the same provider. That is why the permission and proof rows stay separate. Keep the approved target and intended work clear before proceeding.

Choose the bounded profile

Quick samples one homepage and up to two same-origin scripts. Its limits are ten website contacts and ninety seconds. Deep samples a bounded same-origin page set: discovery stops after twenty-five visited pages to reserve requests for other checks. It samples up to twenty scripts, with limits of two hundred website contacts and ten minutes.

These are upper limits, not a promise that every page will be reached or every scan will finish in a particular time. Redirects, retries and follow-up checks use the scan's contact budget. Ownership-file verification is a separate bounded request, not part of that allowance.

The exact authorized public HTTPS origin is the boundary. The website beta does not provide authenticated-browser testing, form submission, mutation requests or active exploitation. A Deep label does not mean unrestricted testing, and a larger budget does not expand your authority to adjacent systems.

Read About our scanner for the current limits and exclusions. The scan-limits article explains what a response observation can and cannot establish about the rest of an application.

Read-only intent does not erase responsibility

HTTP's meaning of a safe method concerns the requested semantics. RFC 9110, section 9.2.1 also explains that implementations can have side effects when handling such requests. That protocol classification does not grant permission to inspect a website or guarantee that a request has no operational effect.

If the scope you have been given excludes particular resources or activity, do not ask a coding tool to work around those restrictions. A repair brief prepares text for your tool; SecurityFuse does not apply or deploy the repair. Review the proposed change and any tests before running them.

Recheck within the same responsibility

A recheck is a new authorized scan, not a continuation of unlimited access from the original report. Confirm the target and current authority, and renew Deep proof when required. Keep a repair statement separate from the fresh evidence collected afterward.

If an owner has a concern about traffic or wants an exclusion reviewed, the scanner page gives the contact and manual handling process. Do not treat a report, a challenge token or this article as a waiver of that owner's boundaries. The useful outcome is a specific, permitted observation that helps someone make a responsible next change.