Trust the browser before you trust the action
Peakhour verifies that the browser ran the issued challenge before high-risk logins, account changes, checkout actions, or browser-backed API calls continue. It gives the risk decision a stronger browser signal without forcing trusted users through visible CAPTCHA friction.
Request shape alone should not decide account trust
Sophisticated automation can reuse headers, cookies, browser claims, and proxy-backed sessions. For sensitive actions, teams need to know whether the browser ran the challenge Peakhour issued for that request.
Header and cookie replay
Automation can copy the outer shape of a browser request without running the browser code behind it.
Login and account actions need higher confidence
A password match or valid session can still be risky before resets, profile changes, saved-card use, or checkout.
Browser trust must be reviewable
Fraud and security teams need to see challenge issued, witness returned, validation result, and policy action in one record.
Make browser trust part of the action decision
Peakhour ties each challenge to a fresh VM blueprint. The browser runs selected challenge slices and returns a witness. The server checks that evidence against the issued challenge before choosing the least disruptive action.
-
Per-request VM blueprint
Generate challenge-specific execution material instead of relying on a static JavaScript token.
-
Browser trust witness
Collect digest and trace evidence from the browser challenge path.
-
Strict replay checks
Validate enforceable slices against the server's expected challenge flow.
-
Policy action
Use valid, missing, malformed, or mismatched witnesses as signals for allow, challenge, throttle, block, or review.
Browser trust stays attached to the decision record
Verified browser trust is strongest when it stays attached to the route, session, account event, policy version, and final action. That record gives fraud and security teams a concrete signal to review without pretending the witness proves everything by itself.
Security teams can separate clients that ran the challenge from scripts that only replay request shape, then choose the least disruptive action that fits the rest of the risk context.
It proves
The issued challenge path produced matching evidence.
- The client returned evidence from the Peakhour challenge path.
- The witness matches the issued challenge material and expected execution slices.
- The result can be attached to a request, route, session, account action, and policy decision.
It does not prove by itself
The user, device, and account are automatically trustworthy.
- The user is human.
- The device is trustworthy.
- The account owner is legitimate.
- The request should be allowed without credential, proxy, device, behaviour, and route context.
Protected journeys where browser trust matters
Risky sign-in
Require a verified browser signal before accepting suspicious logins or deciding step-up friction.
Account state changes
Add witness evidence before password reset, email change, saved address, stored payment, gift-card, or checkout actions.
Browser-backed API actions
Attach browser trust evidence to token, cart, account, and verification API calls that originate from browser sessions.
Fraud and support review
Export challenge and witness outcomes with the rest of the request evidence.
Peakhour Browser Challenge Evidence, Browser trust witness and policy signal
Related evidence
Browser and Account Abuse Reduced in Production
Customer examples that connect Peakhour controls to production outcomes.
Gumtree
Eliminating Bot Traffic and Reclaiming Platform Control
Gumtree, Australia's leading marketplace, battled significant bot traffic that skewed analytics, enabled scammers, and increased infrastructure costs. Peakhour's bot management solution reduced unwanted traffic by 75%, dramatically lowered costs, improved performance, and created a new revenue stream.
Pharmacy Direct
Healthcare Security & Bot Protection Case Study
How Australia's first online pharmacy secured patient data and prevented healthcare fraud with advanced bot protection whilst saving their $900k platform investment.
Connect Verified Browser Trust to Related Controls
Account Takeover Prevention
Use challenge evidence beside credential, session, device, and account-change risk.
Contextual Security
Apply risk-based actions from the full request, device, route, and account context.
API Bot Protection
Separate browser-backed API clients from automation that only replays request shape.
Add verified browser trust before protected actions
Map the login, account, checkout, and browser-backed API actions where replayed request shape is not enough. Peakhour can add browser trust evidence before those actions complete.
Relevant information from our blog
Why Multi-Factor Authentication Alone Can't Stop Account Takeovers
As cybercriminals employ AI and residential proxies to bypass multi-factor authentication, businesses must adopt a multi-layered security approach to protect against account takeovers.
Read More
Residential Proxies, Friend or Foe?
Understand how rotating residential proxy traffic masks automated behaviour and what detection signals matter most.
Read More
Understanding Bot Management: From Basic Protection to Advanced Threat Mitigation
A comprehensive guide to bot management, differentiating between basic, intermediate, and advanced protection strategies against evolving bot threats.
Read More