Website security testing quotes: compare the scope before the price

Does ‘one website’ include the customer portal?

Imagine a company with a marketing site, a customer portal and an API on separate hostnames. A quote naming only the marketing site does not tell you whether the other two are covered. This is a purchasing example, not a customer case. Send the actual URLs and ask the supplier to identify the included target in writing.

Also ask whether the work uses accounts. A visitor looking at public pages and a tester comparing two customer roles have different access and different tasks. Do not infer logged-in coverage from a broad label such as ‘web security’. If the concern is another customer seeing your orders, a public-only check cannot settle that question.

Ask for a finding you could hand to a developer

Request a redacted report sample before paying. Look for the affected location, conditions under which the issue was observed, evidence with sensitive values removed, likely impact and a suggested correction. A screenshot without its conditions can be difficult to reproduce. A long list of scanner alerts can still leave the developer deciding which ones are real.

The sample should also show what was not checked. Ask how uncertain results are labelled and whether a person reviews the evidence. Report length and vulnerability count are poor substitutes for those answers. A check with no findings should still document its agreed scope and limitations; it cannot certify that every part of the system is safe.

What the US$120 Mingxi check means

The standard check concerns one agreed public website or API target without logging in. Subdomains, other applications and additional assets are not silently included. It covers agreed public exposure, basic configuration and verifiable common risks, with an engineer reviewing evidence, severity and remediation advice. Source-code review, logged-in functions, multiple account roles and business-logic testing are excluded.

The PDF report is sent by email in the agreed language. The two-business-day delivery period starts after ownership, authorization, scope, necessary materials and payment are confirmed. Retesting is not included by default; confirm its scope and price separately. Read the current service scope before ordering rather than relying on the price alone.

Keep the agreement with the report

A useful purchase record includes the accepted target, exclusions, deliverable, start conditions and the person who will receive the report. Add the cancellation and scheduling terms actually agreed with the provider. Do not fill missing terms with assumptions.

After a fix, retain the deployment version and the finding it addresses. Ask what evidence a separately arranged retest will provide. A new clean scan of the homepage does not establish that a different, previously affected endpoint was repaired.

Practical checklist

• Send the target URLs and ask what is excluded.
• Confirm whether any login access is part of the work.
• Read a report sample and the delivery start conditions.
• Record retesting and cancellation terms before payment.

A common question

Is a lower-priced check automatically poor value?

No. A small, clearly bounded check can suit a small public site. Compare the work to the risk you need answered. A cheaper public-only check cannot replace an assessment that requires accounts, source code or business-logic testing.