Fraud Detection: Spot Abuse in Your Application Logs

Last verified on Nov 8, 2026.

Abuse and fraud in a web application rarely look like an attack. The requests are valid, the credentials often are too and each action is one your product allows. What gives it away is the shape of the traffic: too many, too fast, too uniform or too concentrated.

This guide covers how to spot fake signups, scraping, promotion abuse and payment fraud from the logs you already have. It is about application-level behavior, not about scoring individual transactions with a fraud model.

The common forms

OWASP maintains a catalog of automated threats to web applications, with a named entry for each. Three of them cover much of what teams run into:

• Account Creation (OAT-019): creating multiple accounts for subsequent misuse.
• Scraping (OAT-011): collecting application content and other data for use elsewhere.
• Carding (OAT-001): multiple payment authorization attempts to verify the validity of bulk stolen payment card data.

Stripe describes the card-testing version of this as someone checking whether stolen card details are valid so they can make purchases, and suggests rate limits on your own endpoints as one control. OWASP's API Security Top 10 lists the wider category as unrestricted access to sensitive business flows.

What the evidence looks like

Abuse leaves a signature in aggregates, not in single lines. Example log excerpt from a signup endpoint during a fake-account run:

09:41:02 POST /signup 201 ip=203.0.113.14 email=kq83x1@mailbox-example.test ua="python-requests/2.31"
09:41:03 POST /signup 201 ip=203.0.113.14 email=pz02m7@mailbox-example.test ua="python-requests/2.31"
09:41:03 POST /signup 201 ip=198.51.100.77 email=ht19c4@mailbox-example.test ua="python-requests/2.31"

Three things stand out: random-looking local parts, one email domain and one client string. No single request is wrong.

Detect it step by step

Log the fields that make grouping possible: client IP, user agent, account ID, email domain, payment method fingerprint, promo code and the outcome. Then run a small set of grouped queries on a schedule.

1. Signups concentrated in a source. Count new accounts per IP, per network and per email domain per hour:

-- Example: email domains with a surge of new accounts compared with their usual share
SELECT split_part(email, '@', 2) AS domain,
       count(*) AS signups_last_hour
FROM signups
WHERE ts >= now() - interval '1 hour'
GROUP BY 1
HAVING count(*) >= 20
ORDER BY signups_last_hour DESC;

2. Card testing. Count payment attempts per client and per card, and the share that fail. A client with many distinct cards and a high decline share is testing numbers.
3. Scraping. Count distinct resource IDs or pages read per client per hour. A person reads dozens; a scraper reads thousands, often in sequence.
4. Promotion abuse. Count redemptions of one code per payment method, shipping address and device, not only per account.
5. Funnel quality. Compare activation after signup (first real action within a day) between suspect and normal cohorts. Fake accounts do not activate.

Thresholds and pitfalls

Start with a ratio against the same hour last week, plus an absolute floor so quiet hours do not alert. Tune the floor against a month of history.

False positives to plan for:

• Many real users can share one address, such as an office, a campus or a mobile carrier network. Group by IP and a second attribute, such as account or device, before acting.
• A launch, a sale or a press mention raises signups and payments for legitimate reasons. Check marketing calendars first.
• Disposable-domain lists go stale. Treat them as a feature of a score, not a verdict.
• Sophisticated bots rotate IPs and user agents, so also group by behavior: identical request timing, identical field-fill speed or the same sequence of routes.

What to do when it fires

Act in proportion. Add or tighten rate limits on the affected route first, since that is reversible. Add a challenge or email verification step for the suspect segment. Hold orders and promotions for review rather than refusing them. Block with an expiry, never permanently, so a shared IP does not lock out real users for good.

For payments, share the affected accounts and attempts with your processor. Afterward, review what the abuse cost you in sends, credits and chargebacks.

Related guides: bots and scraping, authentication anomalies and the wider security monitoring guide. Edge logs from Cloudflare and payment provider events sent through webhooks are common inputs for the grouped queries above.