Next-Gen Attack Surface Management New: PCI DSS 4.0 payment-page monitoring →

Stop testing your WAF.
Start testing your apps.

Modern WAFs create a false sense of security. We find the origin servers your WAF doesn't protect and map every API your frontend calls, so you see what attackers see before they do.

Where other scanners stop, we start.

Most tools look at your perimeter or wait for you to tell them what to test. prayersec reads what your app actually ships, then checks the two things attackers check first: what answers without signing in, and what your WAF is quietly covering for.

JS MAPPER

Your application's attack surface

Paste a URL or a route inside your app. We map every endpoint its JavaScript calls, rank them by attacker interest, check which answer without signing in, and export straight to Burp, ZAP or Postman.

ATTACK SURFACE

Your domain's attack surface

Every hostname and IP under your domain, the services they expose, origin servers that skip your CDN, certificate problems, and email spoofing gaps (SPF, DKIM, DMARC).

What gets scanned
Typical tools: Ports, hostnames and the pages a crawler can click to.
Every script your app ships, including lazily loaded chunks and published source maps, read for the API calls inside.
The WAF
Typical tools: Test through the front door and report what the WAF lets through.
Test through the WAF and straight to any exposed origin, endpoint by endpoint, to show what only the edge is protecting.
“Is it open?”
Typical tools: Hand you a list of endpoints to test yourself.
Check which endpoints answer with no sign-in, and judge whether the response is sensitive, internal or public.
Leaks in your code
Typical tools: Out of scope, or a separate product.
Hardcoded keys and tokens (shown masked), internal hostnames, backend hosts on Azure, AWS, Heroku and more, and open GraphQL schemas.
Change over time
Typical tools: A one-off report.
Rescans on your sprint cadence, with an email or Slack alert listing new endpoints and new findings.
Safety
Typical tools: Often aggressive by default.
Ownership proven first. Endpoint checks send read-only requests with no credentials, and skip anything that looks like it could change data.

A finding only this approach can produce

An admin API your WAF blocks looks safe in every through-the-front-door scan. But if the origin behind it is reachable, the WAF is the only thing standing in the way. We test both paths for every endpoint your JavaScript calls, so you see it before someone else does.

AI analysis runs on models we host ourselves. Your code is never sent to third-party AI services.

HIGH Example finding
GET app.example.com/api/admin/stats
Through the WAF403 · blocked
Direct to origin 203.0.113.7200 · answered
Signed in?no credentials sent
Responseinternal data
Fix: lock the origin so only your CDN can reach it, and enforce access in the application.
JavaScript attack surface

Your frontend is a map of your backend.

Developers ship new API endpoints every sprint. Security finds out at the next pentest. prayersec reads the JavaScript your site already sends to every visitor and turns it into an inventory of the APIs it calls, so security stays in step with what dev shipped.

  • ⌁
    Every call, not just the obvious ones

    fetch, axios, XHR and WebSockets across bundles and lazy-loaded chunks, with URLs built from constants and string concatenation resolved.

  • ▲
    Ranked the way an attacker would

    Login and token flows, file uploads, admin routes and endpoints that take an ID rise to the top, each with a checklist of what to test.

  • +
    See what's new

    Re-mapped on a schedule that matches your sprints and compared with the last map, so endpoints shipped since your previous look stand out.

  • ✓
    Leads you can trust

    Every endpoint is checked against the source code. Anything that can't be found there is clearly marked, never presented as fact.

  • ⇢
    Straight into your tools

    Export an OpenAPI file for Burp, Postman or ZAP, or copy any endpoint as curl or a raw HTTP request.

  • ◆
    Private by design

    Analysis runs on a model on our own hardware. Your code is never sent to a third-party AI service.

FOR SECURITY

Know what shipped before you test it

Start every assessment from an up-to-date list of routes ranked by risk, instead of clicking through the app and hoping you found them all.

FOR DEVELOPERS

See your app the way attackers do

Your frontend already publishes every route it uses. Find the admin and internal ones before someone else does, and fix authorization while the code is fresh.

How it works

Every scan starts with proof of ownership. We only test domains you have verified.

01 / VERIFY

Prove ownership

Add a DNS TXT record or upload a verification file. No verification, no scan.

02 / DISCOVER & MAP

Find origins and APIs

We find servers that answer outside your CDN using certificate logs, DNS and fingerprints, then map the APIs each host's JavaScript calls.

03 / COMPARE

Diff the results

The same tests run through the WAF and direct to origin. Every finding is labeled masked, exposed or blocked.

04 / MONITOR

Stay closed

Rescans on your sprint cadence, every two weeks by default, flag newly exposed origins and newly shipped endpoints, with step-by-step fixes like CDN-only firewall rules.

PAYMENT PAGE MONITORING

Know every script on your checkout.

Card skimmers don't break in through your server. They hide in a script on your payment page: a compromised vendor library, a tampered tag, one extra line of JavaScript. PCI DSS 4.0 now asks merchants to prove they control exactly what runs there.

prayersec watches your payment pages on a schedule you choose, keeps the inventory and authorizations your assessor will ask for, and alerts you the moment something changes.

  • Script inventory of every external and inline script delivered with the page, with a content fingerprint and whether it is pinned with Subresource Integrity.
  • Authorization with a written justification, and who approved it and when. Folder rules cover your own bundles, so a routine release doesn't page anyone.
  • Change and tamper alerts for new scripts, changed scripts and security header changes (CSP, HSTS, X-Frame-Options and more), by email and Slack, Teams or webhook.
  • Your schedule: hourly, every 6 hours, daily or weekly, plus on-demand checks, with a full history kept as evidence.
How it maps to PCI DSS 4.0
6.4.3Manage payment page scripts

Each script authorized, its integrity assured, and an inventory with a written justification for why it is needed.

→ Inventory, content fingerprints and SRI status, and authorizations with justification and approver.

11.6.1Detect changes and tampering

Alert on unauthorized changes to the security-impacting HTTP headers and script contents of payment pages as the browser receives them, at least weekly.

→ Scheduled checks as often as hourly, header baselines, and alerts to the people who need them.

ALERT Example · checkout.example.com/pay
1 authorized script changed, 1 new unauthorized script
cdn.example-widgets.com/chat.jscontent changed
metrics-cdn.example.net/a.jsnot authorized
content-security-policyunchanged
Sent to security@example.com and #payments-alerts · checked hourly

prayersec supports these requirements; your Qualified Security Assessor decides how they apply to your payment pages and whether they are met. Checks cover the scripts and headers delivered with the page.

Services

When you need a human on it

Automation finds the surface. A tester finds what it means. We start from your prayersec map so the time goes into the endpoints that matter, not into rediscovering them.

Web app & API penetration test

Hands-on testing of your web application and its APIs, the way an attacker would approach them.

  • ✓OWASP Top 10 and OWASP API Security Top 10 coverage
  • ✓Authentication, session handling and access control across user roles
  • ✓Business logic flaws scanners can't see (IDOR, workflow abuse, race conditions)
  • ✓Your full attack surface from prayersec, including exposed origins and shadow APIs
You get: a report with risk-rated findings, reproduction steps and fixes, an executive summary, and a retest of what you've fixed.

Threat modeling

A structured look at a system or new feature before it ships, so security is designed in rather than bolted on.

  • ✓Data flow diagram with trust boundaries, built with your engineers
  • ✓STRIDE analysis of every component and data flow
  • ✓Threats ranked by likelihood and impact, with concrete mitigations
  • ✓Works for a whole platform or a single feature in design
You get: the diagram, a prioritized threat register and a mitigation plan your team can turn into tickets.
01 / SCOPE

A short call to agree targets, test windows and rules of engagement, then a written authorization and quote.

02 / TEST

Testing within the agreed scope and window, with a direct line to us if anything critical turns up.

03 / REPORT

Findings your developers can act on, and a walkthrough with your team.

04 / RETEST

We verify your fixes and update the report so you can show the issues are closed.

Request a quote

Every engagement is scoped to your application, so pricing is quoted after a short scoping call. Testing only starts once there is a written agreement.

Prefer email? support@prayersec.com

From the blog

How attack surfaces really get exposed, and what to do about it.

All posts →
JavaScriptAPI security

JavaScript is your hidden attack surface

Every modern web app ships a map of its own backend to every visitor. Here is what is in it, why most security tools never read it, and how prayersec turns it into a tested API inventory.

· 4 min read

Simple pricing

Start free with one domain. Upgrade when you want full results, origin discovery and scheduled scans.

Free
$0

1 domain, one JS attack-surface scan with preview results.

Paid plans
More domains & hosts

Full results, origin discovery, scheduled scans, exports and PCI DSS 4.0 payment-page monitoring. See current prices when you sign in.

Ready to see the truth?

Map your first host in minutes. No card required to start.

Start free