Authorization boundary
Unsupported or unsafe scope is not bypassed by support, billing state, monitoring, credits or customer urgency.
- Block unsupported targets before scanning
- Keep permission traceable
- Use ticket-only fallback when access is unsafe
WebRiskOps Scan Authorization - Allowed targets, scope and limits
Every customer scan must be authorized, scoped and limited before crawler, scanner, report, fix, retest or monitoring work starts.
Trust brief
Confirm the target can be scanned before crawler, report or remediation work starts.
Authorization questions should start from project scope, target ownership, include/exclude boundaries, private path rules and accepted access mode.
Allowed authority evidence
The customer must own the target or have explicit permission for the domain, client site or commercial journey.
Scope controls
Public/private paths, crawl depth, modules and rate limits should be visible before scanner work starts.
Access-mode checks
Code, CMS, tag or platform access is requested only for remediation workflows that need it.
Customer authority requirements
The user must have the right to scan the domain, storefront, application, or account they add to the product.
- Owned or authorized target
- No third-party abuse
- Clear customer responsibility
Allowed targets
Allowed targets include customer-owned public websites, authorized client properties and specific commercial journeys where the customer can confirm permission.
- Owned domains
- Authorized client sites
- Defined commercial journeys
Forbidden third-party and private targets
Forbidden scope includes unrelated third-party sites, admin/private systems without authorization, credential-protected areas without accepted access and targets that invite unsafe testing.
- No unrelated third-party probing
- No private/admin areas without access approval
- No unsafe target classes
Public/private scope, crawl depth, and rate limits
Scan setup must define public and private paths, include/exclude boundaries, crawl depth, module selection, rate limits and expected runtime before work starts.
- Public/private path boundary
- Crawl depth and rate limits
- Module and runtime expectations
Unsupported-scope blocked state
Unsupported scope should block scanner execution, explain the reason, keep an audit trail, and show a revised-scope step or support-form option.
- Blocked before scanner work
- Reason visible to customer
- Audit trail retained
Monitoring authorization
Recurring monitoring requires ongoing authority to check the target and clear customer ownership of alert routing and scan cadence.
- Ongoing permission
- Alert routing owner
- Monitoring cadence visibility
Fix access and access-mode authorization
Code, CMS, GTM, CMP, or platform access is requested only when a customer chooses a remediation workflow that needs it.
- No access required for basic report
- Explicit authorization for fixes
- Ticket-only mode remains possible