DEV Community: Fingerprint

Vibe coding security checklist

Keshia Rose — Tue, 18 Nov 2025 23:50:41 +0000

The rise of vibe coding in 2025

Vibe coding is all the rage lately. If you’re (somehow) unfamiliar with the term, it’s the act of using an AI tool to code and build an application for you. Basically, anyone with an idea can type out a few prompts and spin up an app, launch a product, or start a side hustle without needing to write any code themselves.

These tools are fast, fun, and seem almost magical as you watch your ideas come to life on the screen. But here’s the thing: most vibe coders aren’t developers or even technical. And while this new technology breaks down barriers and makes app building something anyone can do, it also means the apps they generate don’t necessarily follow the best security practices. When you let AI take the wheel, it tends to skip over the boring (but essential) parts like security, leaving plenty of gaps just waiting to be exploited by folks up to no good.

And this isn’t just hypothetical. There are numerous examples out there of people having their vibe-coded apps hacked:

Or creating something they don’t know how to fix:

Those are the folks I’m hoping to help with this checklist. The people who want to take advantage of these amazing new technologies, but still build safely. Use this list as a starting point to confirm (or at least ask your AI tool to double-check) some security essentials before you hit “deploy” on the app you just vibe-coded into existence.

The hidden security risks of vibe coding

Security holes in AI-built apps are more common than most people realize. Take the Tea app, for example. The team left an entire cloud image bucket open to the internet, leaking tens of thousands of personal photos and ID documents. Though it hasn’t been confirmed to be a vibe-coded app, it sure smells like it. That kind of “oops” moment isn’t the result of some elite hacker attack; it’s what happens when security gets left out of the conversation entirely.

The numbers make it even clearer. According to a recent report, nearly seven in ten developers have discovered vulnerabilities introduced by AI-generated code, and one in five reported that these flaws led to serious incidents with real business impact. That’s not just a few bugs here or there; that’s data leaks, service outages, and revenue loss. And even if AI doesn’t burn the house down, it still creates a mess. Sixty-six percent of developers say they now spend more time fixing “almost-right” AI-generated code than writing their own.

Vibe coding makes it easy to ship fast, but just as easy to ship something fragile. Without understanding what’s safe, compliant, or potentially exposing user data, you could end up building a liability instead of a successful product.

The vibe coding security checklist

All right, now for the part that saves you from waking up to an “uh oh” email from your hosting provider. This checklist isn’t meant to turn you into a security engineer, but it’ll help you catch some common mistakes before you launch. You should confirm that each one is being handled appropriately. Either verify it yourself or ask your AI tool to explain how it’s being done in a way that allows you to inspect it. If the AI can’t show you, it probably didn’t do it.

Data handling

Validate all inputs on the backend to block malformed or malicious data.

Anything a user can type, upload, or submit should be treated as if it’s trying to break your app. Start by validating inputs. Every form, query, and request needs clear rules for what’s allowed. If you expect an email address, check that it’s actually an email address. If you expect a number, reject anything else. Don’t rely only on front-end validation; make sure your backend enforces it too.

Restrict file types and sizes, and store uploads outside your main app directory.

File uploads are another common weak spot. Only allow certain file types, set a maximum file size, and store uploads outside your main app directory. Never trust file names or paths provided by users; they’re easy to manipulate and can expose sensitive parts of your system.

Use parameterized queries to prevent SQL injection attacks.

Next, check how your app talks to its database. SQL injection is one of the oldest and easiest attacks to pull off. It happens when someone sneaks database commands into an input field to trick your app into running them. Make sure your AI-generated code uses parameterized queries or prepared statements instead of string concatenation.

These checks stop attackers from injecting SQL or scripts, prevent bad data from crashing your app, and block oversized or malicious uploads that could eat up resources or expose user data.

Escape HTML in user content to stop cross-site scripting (XSS).

Finally, sanitize your output. When your app displays user-generated content, escape HTML characters to prevent cross-site scripting (XSS). XSS happens when an attacker injects malicious scripts into pages viewed by other users, allowing them to steal cookies, perform actions on behalf of others, or display fake content. If your AI built a template or component that prints user input directly into the page, make sure it escapes that content properly. One unchecked field is all it takes to compromise your users.

Authentication and session security

Use strong authentication with salted password hashing and optional MFA.

Authentication is hard, and you probably shouldn’t try to roll your own. Always use a reputable library or service for handling credentials. If you insist on doing it yourself, make sure any stored passwords are hashed and salted. Hashing turns a password into a one-way value that can’t be reversed, and salting adds randomness to protect against rainbow table attacks, where precomputed lists are used to crack hashed passwords. If your AI tool wrote your auth system, confirm it isn’t storing passwords in plain text. If possible, add multi-factor authentication (MFA), since it’s one of the easiest ways to prevent account takeovers.

Enforce access control checks on every route, not just at login.

Next, apply access controls beyond the login page. Authentication confirms who someone is, while authorization determines what they can do. Every sensitive route or admin action should verify that the user has permission to access it. Without these checks, anyone who’s logged in (or worse, anyone who can guess a URL) could access data they shouldn’t.

Mark cookies as HttpOnly, Secure, and SameSite to protect sessions.

Also, make sure to protect your sessions with secure cookies. Set cookies to “HttpOnly” so JavaScript can’t read them, “Secure” so they’re only sent over HTTPS, and “SameSite” to reduce cross-site request forgery (CSRF) risks. Skipping these flags leaves your sessions vulnerable to hijacking or unauthorized use.

Use device intelligence to add an additional layer of protection.

In addition to these steps, using Fingerprint adds another layer of protection to your authentication system. Each device gets a unique visitor ID, helping you recognize returning users even if they clear cookies or switch browsers. Smart Signals provide extra context by detecting things like automation, virtual machines, or mismatched network details. These signals can help you block suspicious logins, detect session hijacking attempts, and flag risky behavior before it turns into account abuse.

Infrastructure and configuration

Force all traffic over HTTPS and block insecure HTTP requests.

Your app’s infrastructure and configuration set the foundation for its security. Start by forcing all traffic over HTTPS. HTTP sends data in plain text, which means anyone on the same network can intercept or alter requests. Redirect every HTTP request to HTTPS and make sure your SSL certificate is valid and renews automatically. Thankfully, many hosting providers do this for you, though you may need to change settings to ensure it’s always enforced.

Store secrets in environment variables or a secrets manager, never in code.

Store secrets like API keys, database passwords, and access tokens in a safe location and never commit them to source control like GitHub. They should live in environment variables or a secrets manager, never hard-coded in your codebase. If your AI tool generated your project, check that it didn’t sneak credentials into a random config file that’s being committed.

Require authentication and proper CORS settings for all API endpoints.

Extending a bit on the authentication steps mentioned above, also secure your APIs. Every endpoint should require authentication and define strict CORS settings. CORS settings control which external domains are allowed to interact with your API and what types of requests they can make. Avoid using a wildcard “*” origin in production and limit access to trusted domains only. This prevents data exposure through unapproved clients or cross-site attacks.

Regularly update dependencies and remove unused or vulnerable packages.

Outdated or abandoned packages are one of the fastest ways to get compromised. Update regularly, run security audits, and remove anything you’re not using. According to a report by Endor Labs, 49% of the dependencies added by AI coding agents contain known vulnerabilities. Even a single stale dependency can open a hole in your app.

App behavior and resilience

Add rate limiting to prevent abuse and brute-force attacks.

Add rate limiting to protect your endpoints from brute-force logins, credential stuffing, or denial-of-service attempts. Set reasonable thresholds based on user actions, like login attempts, form submissions, or API calls, and respond with temporary blocks or delays when limits are hit. To go a step further, use device intelligence tools like Fingerprint to accurately identify repeat abusers even if they change IPs, clear cookies, or switch browsers. Combining rate limits with device-level identification helps you block persistent attackers without disrupting legitimate users.

Log only what’s necessary and never include secrets, tokens, or personal data.

When something breaks, don’t hand attackers extra information. Show users generic error messages like “Something went wrong” and keep detailed stack traces or database errors in your private logs. Those details can reveal technologies, file paths, or query structures that make an attacker’s job easier. At the same time, log only what’s necessary to debug or investigate issues. Never record passwords, tokens, or personal data, and avoid dumping entire request bodies. Assume your logs could one day be seen by someone else, and write them accordingly.

Good vibes only

Vibe coding is one of the coolest ways to bring ideas to life fast. But moving fast shouldn’t mean skipping the basics of security. A little awareness about input validation, authentication, API security, and session handling goes a long way toward keeping your app and your users safe.

The checklist in this guide gives you the essentials to confirm or ask your AI to verify before you hit deploy, so your next project ships with fewer surprises and more confidence. At the end of the day, no matter how capable your AI tool seems, you need to stay in control of what it builds and how it protects your users.

If you’re ready to go beyond the basics, Fingerprint can help. Our device intelligence platform adds another layer of defense with unique visitor identification and Smart Signals that catch suspicious activity early. If you want to talk about how we can make your vibe-coded app more secure, get in touch with us.

Tutorial: Outsmarting VPNs — prevent regional pricing fraud with true location detection

Keshia Rose — Wed, 12 Mar 2025 23:32:51 +0000

Written by Keshia Rose

When selling products or services globally, businesses often adjust pricing to match local markets, accounting for things like price sensitivity and purchasing power. It’s a win-win: businesses capture a larger market share, and customers in lower-income regions get access to goods and services they otherwise couldn’t afford. But, of course, some people just have to ruin it for everyone. Why should someone in your region pay half the price just because they flipped on a VPN and pretended to be somewhere else?

Detecting a user’s true location is key to protecting your regional pricing strategy and shutting down this kind of abuse. That way, you can block fraud and keep things fair for your real customers. In this article, we’ll dive into how regional pricing fraud works, the headaches of dealing with masked locations, and how Fingerprint can help you outsmart these cheaters and keep your business protected.

What is regional pricing?

Regional pricing is the practice of charging different prices for the same goods or services based on where the customer lives. Depending on the business, “region” could mean a country, a continent, or even a shared currency. Before setting these different prices, businesses need to dive into data like currency value, average income, demand, and competition in each region.

The aim is to strike a balance between affordability for customers and profitability for the business. When done right, regional pricing offers:

Increased accessibility: Making goods and services affordable for customers in lower-income regions.
Expanded market share: Attracting a wider audience by tailoring prices to local conditions.
Maximized revenue: Charging higher prices in affluent regions to capture greater profits.
Competitive edge: Staying aligned with local pricing expectations to compete effectively.

While regional pricing can be applied in almost any industry, it’s particularly common in subscription-based software, streaming services, gaming, travel, and e-commerce. An easy way to see this in action is on the Steam gaming platform, which allows developers to set prices by currency (e.g., Chilean Peso) and region (e.g., South Asia).

For instance, as of this writing, the price of Baldur’s Gate 3 on Steam ranges from $19.50 in Russia (1999 ₽) to $76.51 in Switzerland (CHF 69.99). Steam even does some of the heavy lifting, offering pricing guidance that can be especially handy for smaller shops or indie devs who don’t have the time or resources for extensive market research. This pricing makes games more accessible for lower-income regions while staying profitable for developers. However, it also attracts fraudsters looking to exploit the system.

How fraudsters hide their real location

Fraudsters are nothing if not resourceful when it comes to dodging regional pricing rules. They leverage various tools and tricks to mask their true location and access lower regional prices. Here are some of the most common methods:

Employing proxies and anonymizing networks

Proxies act as intermediaries that reroute internet traffic through a different location. Fraudsters can use them to fake their IP address and appear to be in another region. For extra anonymity, some use Tor (the onion router), which encrypts traffic within its network and routes their traffic through multiple relays, making location detection even harder.

Using a VPN

Virtual Private Networks (VPNs) work similarly to proxies by routing traffic through remote servers. Unlike proxies, VPNs encrypt all traffic and operate at the system level, affecting all internet activity on a device. This adds some additional security in addition to masking their location in order to bypass restrictions.

Falsifying account information

In cases where pricing is tied to user profiles, fraudsters may simply lie about their location. They might enter fake addresses or billing details during sign-up to mimic a cheaper region. For example, someone might claim to live in India while actually residing in France.

Exploiting cross-border payment methods

Some fraudsters bypass location restrictions by using payment methods associated with cheaper regions. Setting up accounts tied to international banks can allow them to appear as though they’re making purchases locally.

Sharing accounts across regions

Shared or resold accounts are another common tactic to access cheaper regional pricing. A fraudster might buy a subscription at a lower price in a cheaper region and then sell access to users in higher-priced regions. Streaming services, in particular, tend to be vulnerable to this type of abuse.

Modifying browser settings

Some fraudsters manipulate their browser settings to align with the region they want to target. This includes changing the browser’s language, time zone, or geolocation data. For example, a browser set to display Spanish and use the Argentina Time (ART) time zone might trick basic detection systems into thinking the user is in Argentina.

Detecting users’ true location with Fingerprint

Without accurate location detection, fraudsters can slip through the cracks, undermining your carefully designed pricing model. While basic methods like simple IP-based geolocation provide some insight, they can be easily spoofed, leading to inaccurate location data. You need more advanced techniques to see through tools like VPNs, proxies, and spoofed data.

That’s where Fingerprint can help. Fingerprint’s Smart Signals give you everything you need to detect user locations and enforce a regional pricing strategy that fraudsters can’t bypass. Fingerprint provides a simple client agent that runs on key pages, like login or checkout, and analyzes over 100 attributes from a user’s browser and device. This data is used to create a unique visitor identifier to recognize trusted devices, but more importantly, it is also used to detect key signals and attributes to help you gauge user risk and intent.

For region-based policies, the most relevant signals are IP Geolocation, VPN Detection, and Geolocation Spoofing Detection for mobile devices.

IP Geolocation: Pinpoints the physical location of the true originating IP address. We use multiple techniques to detect the client’s true IP, even when anonymizing tools are in use, ensuring accurate visitor location.
VPN Detection: Identifies VPN usage by analyzing factors like mismatched time zones, operating system settings, and connections from known VPN providers. This signal returns a simple boolean indicating if a VPN is in use, along with a confidence level for the detection. It also returns which methods were flagged, as well as the originating time zone and country. Check out our article on how VPN detection works for a detailed breakdown of the techniques involved.
Geolocation Spoofing Detection: Specifically for mobile devices, this signal flags when geolocation data appears to have been tampered with, returning a boolean for easy implementation.
IP Blocklist Matching: Available for Enterprise customers, this signal identifies whether a user’s IP address originates from a known Tor exit node or a public proxy provider, giving you additional insights into potential bypassing tactics.

How to enforce regional pricing

With Fingerprint Smart Signals, you can pinpoint users’ true locations and catch anyone trying to bypass your regional pricing strategy. Here’s how you can leverage the IP Geolocation and VPN Detection signals to make it happen.

First, you’ll need a Fingerprint account (sign up for a free trial if you don’t already have one) and your API keys from the Fingerprint dashboard. This tutorial will use the Fingerprint CDN and Node SDK, but we have a variety of SDKs for your favorite framework or language.

While testing, it’s a good idea to disable any ad blockers because they might interfere with loading Fingerprint scripts from the CDN. For production, you can bypass this issue with a proxy integration, but that’s beyond the scope of this tutorial.

1. Add the client agent to your checkout

To access the geolocation and VPN signals from Fingerprint, you’ll first need to make an identification request on the pages where accurate location data is required. This example is for a checkout page where a user can activate regional pricing. Load the Fingerprint client agent as early as possible, and then call the get() method to make an identification request exactly when you need it.

// Initialize the agent as soon as possible
const fpPromise = import("https://fpjscdn.net/v3/YOUR_PUBLIC_API_KEY").then(
  (FingerprintJS) => FingerprintJS.load()
);

async function getRegionalPricing(orderDetails) {
  // Request identification data when you need it.
  const fp = await fpPromise;
  const result = await fp.get();
  const { requestId, sealedResult } = result;

  // Include the requestId and/or sealedResult with the order details
  const orderPayload = {
    ...orderDetails,
    requestId,
    sealedResult
  };

  const requestOptions = {
    method: "POST",
    body: JSON.stringify(orderPayload),
    headers: {
      "Content-Type": "application/json",
      Accept: "application/json",
    },
  };

  // Send the order payload to your server
  const response = await fetch("/api/regional-pricing", requestOptions);

  // ... additional order logic
}

2. Retrieve the signals server-side

There are several ways to retrieve the generated Smart Signals on your server. After making an identification request on the client side, you can pass the returned requestId to your server and use the Fingerprint Server API to fetch the full identification event results.

Alternatively, you can set up webhooks to send identification event results directly to an endpoint on your server, linking them using the requestId from the client side. Another option is to receive the full identification event results directly on the client side in encrypted form as a sealedResult, then pass them to your server for decryption.

In this tutorial, we’ll use the encrypted client-side approach, known as Sealed Client Results. We recommend this method because it reduces latency by eliminating the need for an additional request to retrieve the identification event details on your server. Import one of our server SDKs and use the unsealEventsResponse method along with the sealedResult sent from the client side and your encryption key to unseal the data.

  const {
    unsealEventsResponse,
  } = require("@fingerprintjs/fingerprintjs-pro-server-api");

  const { sealedResult } = request.body;
  const decryptionKey = "YOUR_ENCRYPTION_KEY"

  const unsealedData = await unsealEventsResponse(
    Buffer.from(sealedResult, "base64"),
    [
      {
        key: Buffer.from(decryptionKey, "base64"),
        algorithm: "aes-256-gcm",
      },
    ]
  );

3. Extract geolocation and VPN use details

Now that we have the full identification event data decrypted, pull out the specific information we need: the actual geolocation and whether or not VPN has been detected.

  const location = unsealedData?.products?.ipInfo?.data?.v4?.geolocation;
  const vpnDetection = unsealedData?.products?.vpn?.data;

You can see more details on the result data in the Server API reference but here is an example of the geolocation object:

{
  "accuracyRadius": 20, // in km
  "latitude": 50.05,
  "longitude": 14.4,
  "postalCode": "150 00",
  "timezone": "Europe/Prague",
  "city": {
    "name": "Prague"
  },
  "country": {
    "code": "CZ",
    "name": "Czechia"
  },
  "continent": {
    "code": "EU",
    "name": "Europe"
  },
  "subdivisions": [
    {
      "isoCode": "10",
      "name": "Hlavni mesto Praha"
    }
  ]
}

While the VPN detection output looks like this:

{
  "result": true,
  "confidence": "high",
  "originTimezone": "Europe/Prague",
  "originCountry": "unknown" // Not yet supported for browsers
  "methods": {
    "timezoneMismatch": true,
    "publicVPN": true,
    "auxiliaryMobile": false, // Irrelevant for browsers, mobile SDKs only
    "osMismatch": true,
    "relay": true
  }
}

4. Block VPN and enforce regional pricing based on true location

Next, we’ll use this data to determine the appropriate price based on the user’s actual location and block regional pricing if VPN use is detected. Start by using the true geolocation to determine the correct pricing.

In this example, pricing is based on the user’s country, and we’ll use a pseudo-function to look up the corresponding price.

const countryPrice = getCountryPrice(location?.country?.code);

You’re now using the user’s true location information instead of the location they’re pretending to be in. Before sending the price back to the client, you can also check for VPN usage and block transactions over VPNs for added protection against regional pricing fraud.

One thing to note is that anonymizing services like Apple’s iCloud Private Relay can trigger a VPN detection, even if the user has not changed their presenting location using the service. In those cases, you can choose to still return a successful response.

if (
  vpnDetection?.methods?.relay === true &&
  vpnDetection?.methods?.timezoneMismatch === false
) {
  return {
    success: true,
    price: countryPrice,
  };
}

In all other cases where VPNs are detected, you can choose to block the regional pricing.

  if (vpnDetection?.result === true) {
    return {
      success: false,
      message:
        "It looks like you are using a VPN. Please turn it off and use a regular local internet connection before activating regional pricing.",
    };
  }

Stay ahead of fraudsters with smarter data

Regional pricing only works if you can enforce it, and fraudsters using VPNs and proxies are ready to bypass your rules. If you want to keep your pricing strategy intact, you need reliable tools that can cut through their tricks and reveal users’ true locations. With Fingerprint’s Smart Signals you can accurately identify users’ real locations, enforce fair pricing, and block regional pricing fraud with ease.

Ready to see it in action? Try it out in our demo or contact our team to learn how Fingerprint can help secure your regional pricing strategy.

Tutorial: How to protect your business from referral fraud

Keshia Rose — Wed, 05 Feb 2025 15:17:00 +0000

Written by Martin Capodici

What is referral fraud?

Referral programs are used by hundreds of brands, including T-Mobile, Grubhub, American Express, to drive more sales by rewarding people or businesses that promote their products.

Referral fraud is the abuse of these programs by fraudsters to make money and obtain unfair discounts.

Fraudulent referrals are costly, both in terms of money paid to people who don’t deserve it and time spent investigating the fraud. In some cases, credit card fraud accompanies referral fraud, causing additional costs due to refunds and chargebacks.

A 2023 study revealed that 25% of merchants experienced referral fraud, and 34% experienced coupon and discount abuse, which is often related to referral fraud.

How do referral programs work?

A referral program rewards promoters according to a result that is beneficial to the business. Here are some examples:

Ride-sharing company Easyride offers customers $20 credit if they get a friend to sign up and spend $20.
A weightlifting blogger advertises Apex Strength gym on each of their posts. The gym pays the promoter $10 for every person who uses their referral code for a free day pass.
Level Up Books is a service that sends out curated book recommendations to managers. They sign up with Amazon to receive a percentage of all books sold as a result of links clicked in their emails.

There are various ways of tracking the performance of referrers, such as the number of clicks, sign-ups, or percentage of sales. This leads to numerous types of referral fraud, each designed to exploit specific weaknesses of the referral program. For example, if you pay a referrer when an account is created with only an email address, they could make a lot of money creating dozens of fake accounts.

Types of referral fraud

Let’s look at the main categories of referral fraud. While some of these are outright criminal, others, such as breaking the terms of service of a site or exploiting a loophole, are in a gray area.

Fake new customers

As I mentioned earlier, when a referral program pays per sign-up, fraudsters can exploit this by creating fake accounts.

To create enough fake accounts to make this enterprise worthwhile, the fraudsters use bots to create the accounts automatically. These bots can spoof different devices and use different IP addresses using a VPN to evade simple bot or device detection that only relies on IP addresses. Device intelligence, which we will cover later, can help detect these bots.

If the referral program requires the referred customer to make a successful purchase, the fraudster can use a stolen credit card to make purchases. They will send the item to the cardholder’s billing address if known, or a random address, and profit from the payouts from the referral program.

When the business finds out it was a fraudulent transaction, they may have already paid the fraudulent referrer, will have incurred a loss due to the cost of the sent goods, and may have to pay chargeback fees to their payment processor.

Referral farming

Unique discount codes can be used to track who referred someone to a product. For example, let’s say a YouTube channel called “Shirley’s Health” advertises that a vitamin supplement is 30% off. They tell viewers to use the discount code SHIRLEY. A share of revenue from sales that use the discount code goes to the channel.

Referral farming is a scheme where the fraudster uploads their unique discount code to promo-code sharing sites. Customers who use these sites typically have decided to buy something, have the order page open, and are now hunting for a discount code. If the fraudster’s discount code is used, they get paid for sales they didn’t help generate — which is a waste of money for the referral program.

Return abuse

Return abuse involves referring someone but arranging with them to return the product for a full refund once the referral payout has been made. It takes advantage of both generous return policies and the timing of payouts.

Return abuse requires coordination with the person returning the goods and cutting them in on the deal — or a fraudster can just set up another fake account to be that “other person,” which requires much less coordination and allows them to keep the full payout amount. Customers who constantly return items get banned by retailers. Therefore, it doesn’t scale as well as other methods of referral fraud.

Account cycling

Some referral programs pay based on new account sign-ups. These may pay as soon as an account is verified or only when the new account makes a purchase.

In either case, account cycling can be used as a referral fraud technique. The idea is to refer a friend to open an account and collect the referral fee. Then, the friend closes the account and uses the referral link or code again to reopen the account with the same details.

Some referral programs require a transaction after sign-up, which reduces the risk of account cycling but doesn’t eliminate it. It can still be attractive for friends to cycle accounts for each other for products they intend to buy frequently, such as food deliveries.

Impact of referral fraud

Referral fraud has financial repercussions for your referral program and should be taken seriously.

Here are the ways this can happen:

Fraudsters get paid: If the fraudster gets their referral payment before they are caught, your money is lost.
You get hit with chargebacks: When a stolen credit card is used, you will need to refund the charge, in addition to paying chargeback fees.
Customers get unintended discounts: Account cycling and referral farming can result in your giving additional discounts that are not budgeted for.
Your team wastes time: Dealing with refunds, chargebacks, blocking accounts, and investigations wastes your team’s time on fraud mitigation when they could be focusing on something else to help drive more revenue.
Marketing is negatively impacted: Your marketing campaigns are less effective because money is diverted from genuine referrers to fraudsters. Tracking campaigns also becomes more challenging because fraudulent referrals skew marketing data.

Detecting and preventing referral fraud

Verify referrer details

Asking for more information from referrers will discourage fraudsters because it will force them to reveal their identity or spend money to create fake personas. Asking for email verification, a valid phone number, or government-issued ID documents will reduce referral fraud. However, there is a balance between obtaining just enough verification to prevent fraud and too much verification since you don’t want to deter genuine referrers from signing up and promoting your company.

Verify referral actions

Consider how you calculate a referrer's payment and the timing of that payment. If it is too easy to get paid — e.g., a sign-up with no sale counts as a referral — then it is easier for the fraudster to meet the payment conditions without generating any real business.

To verify the referral action, you can require that the referred customer has spent above a certain amount and hasn’t made a return within the return period. If you reward referrers for leads, only pay out the referrer once the lead is marked in your database as genuine; e.g., after you have spoken to them. This requires more time and effort but it is worth it to avoid losing money to fraudsters.

Monitor referral activity

Your marketing team is likely tracking referral activity to see which campaigns are successful, and finance may be tracking them for profitability. Using the same data, you can also look for unusual patterns that indicate fraud might be happening. For example:

A new or dormant account suddenly generates a high volume of referrals in a short amount of time.
The number of new accounts created on a particular day is much higher than usual, and you do not know why.
Customers signing up from countries or states that are out of the ordinary for your business.

Set referral limits

Referral limits let you automate decisions about suspicious activity in a simple way: You can set a monthly limit on how much a referrer can earn. These limits can then be increased for trusted referrers you know, have interviewed, or have generated a lot of legitimate business.

Analyze traffic sources

You can keep track of the IP addresses of users creating accounts and check if those IPs are on known blocklists. You can also check if the same IP addresses are involved with multiple accounts since such activity can be considered a red flag and worth investigating further.

Block automated abuse

Referral fraudsters use bots to create accounts in bulk automatically. Bots are software that imitates a genuine user and a browser, and takes commands from the fraudster. They are often run from different IP addresses in an attempt to evade detection.

Bot usage can be detected by analyzing traffic sources, checking for device reuse, and monitoring referral activity. You can also determine how long it takes for someone to sign up or perform specific actions — if they are too fast, they might be a bot.

Check for device reuse

The standard techniques to detect device reuse across new accounts are to set a cookie or check IP addresses. Reusing the same device to create multiple accounts is almost certainly a sign of referral fraud or foul play. You can put automatic payment holds on those referrers while they are investigated.

However, it’s also important to remember that IP addresses are sometimes shared between different people using the same internet service provider (such as students on college campuses). This makes IP reuse a red flag, but this alone is insufficient evidence to ban a customer account. Additionally, cookies-based checks are not foolproof since cookies can be cleared in the browser.

Fingerprint device intelligence and Smart Signals

Determined referral fraudsters will use various methods to hide their activity and evade simple detection systems, such as those checking IP addresses. They can launch fraud campaigns using bot networks, VPNs, Tor, compromised cloud accounts, and more.

To defend against these sophisticated techniques for avoiding detection, Fingerprint device intelligence creates a unique digital fingerprint, a visitor identifier, for online browsers and devices accessing your website or application. This visitor ID can detect suspicious devices or behavioral patterns in real time.

Fingerprint analyzes over 100 device attributes like browser configurations, operating system details, and hardware settings to accurately recognize returning visitors.

Additionally, Fingerprint’s Smart Signals provides information about your visitors that is useful for detecting suspicious activity, such as whether they are using a VPN or are a bot. Fingerprint’s API provides a “Suspect Score” for each device that you can use to assess the risk of dealing with that visitor.

Tutorial: Use Fingerprint to prevent fraud against your referral program

In this tutorial, we will use tools from Fingerprint to protect a site against referral fraud. This could be any site with referrals, such as an e-commerce site, a survey site that pays per survey completed, or a business with an offline component completed in person, such as a law firm.

We will use Node.js for our examples. If you use another technology stack, Fingerprint has libraries for all the popular frameworks and languages.

Getting started

First, create a Fingerprint account and open your API keys page. Create a public key now. Keep this page open to copy keys into your code when needed.

Note: If you’re using an ad blocker, your implementation may not work. Simply turn it off while testing, and learn more about how to protect your production Fingerprint implementation from ad blockers in our documentation.

Linking accounts to the device

The Fingerprint visitor ID uniquely identifies a browser or native mobile device. It enables you to detect when a device has been used before on your site, and then link that device to other information you have such as the email address they used, if they have provided one.

In the first part of the tutorial, we will link new accounts with their visitor ID (which represents the unique device) to spot whether someone is creating many new accounts from the same device. We will then automatically block new accounts made from the same device.

First, install the Fingerprint API on the sign-up page you must protect, replacing the PUBLIC_API_KEY with the public key from your API keys page.

<script>
  const fpPromise = import('https://fpjscdn.net/v3/PUBLIC_API_KEY')
    .then(FingerprintJS => FingerprintJS.load());
</script>

In this scenario, we have a sign-up page that requires an email and password. When the user clicks Sign Up, we can resolve the promise shown above and use fp.get() to instruct Fingerprint to store information about the visitor, their device, and the time of the visit.

<script>
  document.querySelector('#signup-form').addEventListener('submit', async (evt) => {
    evt.preventDefault();

    const fp = await fpPromise;
    const result = await fp.get();
    const requestId = result.requestId;

    const email = document.querySelector('#email').value;
    const password = document.querySelector('#password').value;

    // Send the requestId along with the request you want to protect from suspicious behavior
    fetch('/signup', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({ requestId: requestId, email: email, password: password }),
    });
  });
</script>

It is possible for a fraudster to change or remove the requestId variable, but that won’t help them bypass the check. Fingerprint can detect this behavior when we verify requestId on the server.

We will now add the Node.js server code to verify the request ID and get the associated Fingerprint visitor ID used to identify the device. We can then check if the same device has recently performed a sign-up. Create a private key in API keys, replace <<Private Api Key>> with that key, and change the region to match yours.

const express = require("express");
const app = express();
app.use(express.json());

const {
  FingerprintJsServerApiClient,
  Region,
} = require("@fingerprintjs/fingerprintjs-pro-server-api");

const client = new FingerprintJsServerApiClient({
  apiKey: " <<Private Api Key>>",
  region: Region.Global,
});

app.get("/", (req, res) => {
  res.sendFile(__dirname + "/index.html");
});

app.post("/signup", async (req, res, next) => {
  try {
    const { requestId, email, password } = req.body;
    const event = await client.getEvent(requestId);
    const visitorId = event.products.identification.data.visitorId;

    // Check how many times this visitor has created an account
    const queryResult = await sqlClient.query(
      "select count(*) as count from user where created > NOW() - INTERVAL '30 DAY' WHERE visitorid = $1",
      [visitorId]
    );

    // Device has been used to create an account more than twice in the last 30 days, disallow this.
    if (queryResult.rows[0].count > 2) {
      req.sendStatus(403);
      return;
    }

    const userId = await createUser(email, password);

    // Link visitorId (i.e. the device) to the user
    await sqlClient.query("update user set visitorid = $1 where userid = $2", [
      visitorId,
      userId,
    ]);

    res.sendStatus(200);
  } catch (err) {
    next(err);
  }
});

app.listen(3000, () => {
  console.log("Listening on port 3000");
});

Using Fingerprint bot detection to detect automated tools

We now want to add bot detection to protect against the mass creation of accounts. This will protect the site from referral fraud and other unwanted activity that uses bots.

Fingerprint’s Smart Signals includes a bot detection tool that can tell you if the visitor is likely a bot and, if so, whether it is a “good bot” like a web crawler or a “bad bot” — e.g., someone trying to defraud your site in some way.

We will check the event data object to see if the visitor is likely a bot. In this case, we will reject signups from any kind of bot (good or bad) since we only want human sign-ups:

 const botDetection = event.products.botd.data.bot.result;
  if (botDetection != "notDetected") {
    req.sendStatus(403);
    return;
  }

  // Check how many times this visitor has created an account
  // ...

Key takeaways

Referral fraud wastes time and money while detracting from the marketing goals of the referral program. You should protect against referral fraud using various methods, including monitoring and limits, as well as device intelligence solutions like Fingerprint.

To try Fingerprint now, check out our Getting Started Guide or contact our team to learn more.

Tutorial: Credit card cracking explained — and how to prevent it

Keshia Rose — Thu, 30 Jan 2025 17:36:41 +0000

Written by Martin Capodici

If you see an unexpected surge of small transactions in your online store, you might be excited — you have new customers! However, watch out, as this could well be a type of credit card fraud called card cracking.

Card crackers make small payments that test different expiration dates and security (CVV) codes until they find the ones that work. They do this to discover the correct details for a card.

Credit card cracking, also called card testing, creates additional costs for the merchant due to a chargeback fee for each disputed transaction. If this happens too often, the payment processor may increase their general fees. This is a growing problem: about $18 billion was lost worldwide to credit card fraud in 2014, rising to over $32 billion in 2022.

How can you prevent this from happening on your site? In this tutorial, we will talk through the main layers of defenses you can build against this threat. We will then go through code examples using Fingerprint to better protect an e-commerce site.

What is card cracking?

Card cracking is part of a process in which fraudsters attempt to obtain working credit cards that they can use to make illegal purchases.

First, they purchase a list of credit card numbers from an illicit source, often on the dark web. These numbers may have been skimmed from physical card readers, exposed in a data breach, or entered online into scam forms. However, these lists may not have the necessary information to successfully make a purchase since you usually need the expiration date, the security code, and sometimes other information, too.

The credit card cracker attempts to make small payments by guessing the missing information. Because the fraudster has a lot of card numbers and a few tries for each card, they eventually will succeed in finding the right combination. Once they have a working card with all the information, they can then go on to make bigger transactions.

Card testing is a similar practice to card cracking. With card testing, the fraudster has the full card information to begin with, and they perform a test payment to verify that the card is still valid.

Impact of credit card cracking

Card cracking affects merchants in many ways, including:

Financial losses: Merchants must refund payments from unauthorized transactions made with cracked credit cards and also pay chargeback fees. If the merchant has shipped or delivered anything, that is an additional cost. On top of that, if said merchant has too many chargebacks, the payment provider may punish the merchant with extra fees or less favorable terms.
Operational costs: Sellers must investigate and monitor fraudulent transactions, including credit card cracking, to avoid shipping products or providing services when they occur. They also need to decide how to manage or reduce the occurrence of these events.
Reputational damage: For reputable brands, their name appearing on card statements as fraud could result in negative reviews and word of mouth. Additionally, if word gets out that a merchant has allowed card-cracking transactions, this could cause more attempts.

How do card cracking attacks work?

Card cracking needs to be fast. The idea is to test a large number of cards and find the needle in a haystack; that is, a card that works and doesn’t get blocked when attempting to crack it. In addition, as a fraudster, you want to avoid detection. Fraudsters using the same browser and computer with the same IP address run a higher risk of being spotted by even the most basic detection systems.

To test a large number of cards quickly and evade detection, here are some tools crackers use:

Automated bots: These will run through lists of credit cards and possible details, testing them out on different sites. Bots run in parallel, taking instructions from a central command for rapid testing and elimination.
Device/browser spoofing: When using bots, the card cracker will want to make it look like a human is interacting with the site. One way to appear less bot-like is to spoof (pretend to be) the browser of a legitimate customer. This can be done by automating a real web browser so that the actions, typing, and button clicking are happening on an actual screen.
Multiple IPs/VPNs: Sites can block IP addresses, which are network identifiers that provide some idea of who is visiting the site. Card crackers will use a virtual private network (VPN), which lets them switch to different IP addresses as needed to avoid being blocked.
Botnets: Computers infected with viruses can be remote-controlled, and a fleet of infected computers is called a botnet. For the cracker, these bots have the advantage of having home internet IP addresses, which are much less likely than VPNs to be blocked.

Ways to detect and prevent card cracking scams

Credit card cracking is a fairly sophisticated technique. Luckily, there are many ways to detect card cracking and fraud in general, including:

Payment processor tools

Many merchants use a payment processor, like Stripe, instead of working directly with Mastercard or Visa. These payment processors often provide tools to help detect credit card cracking and other fraud. One example is Stripe Radar, which uses machine learning to detect fraud and is built into Stripe’s payment services.

Payment processor tools like Stripe Radar only use financial data to detect fraud and do not look at information about the visitor and their device. Therefore, we recommend pairing them with other strategies in this list, such as device intelligence, to block fraud attempts that the payment processor’s tools may miss.

Card authorization techniques

3DS, or 3D Secure, is a technique that requires additional security verification from a customer. It is a technical standard from Visa and Mastercard that redirects customers to their credit card issuer for authentication. The customer will be asked to provide a password or a one-time code sent to their phone. This is an excellent method to foil card crackers, but unfortunately, it adds additional friction for the user and relies on the issuing bank to implement 3DS, and not all have done so.

Pre-authorization holds

A pre-authorization hold refers to the process where funds are secured from the cardholder but not immediately processed. This is often used in hospitality; for example, when booking a hotel room or a table at a popular restaurant. It can also be used for other kinds of e-commerce purchases (although it is rarer).

Pre-authorization holds may deter credit card cracking because the cracker needs to wait for the final transaction to complete. However, using a hold is a significant change to the customer experience, so it needs to make sense for the business.

Transaction velocity monitoring

Profitable cracking requires attempting thousands of test payments reasonably quickly. If you’re monitoring usage patterns, this may look like an unusual spike in activity. For example, if a fraudster uses a single account to do this, that merchant can keep track of how many different cards have been successfully or unsuccessfully used in the last 24 hours, 7 days, or longer. The merchant can put that account on hold for manual review if the count is suspiciously high.

Device intelligence and fingerprinting

Device fingerprinting provides a unique identifier for a single device that is hard to change. This device intelligence can detect when a fraudster is using the same device to impersonate multiple people. This is possible because information about the device and its connection is revealed when you visit any website. In addition, device intelligence systems can detect potentially suspicious activity, such as when a virtual machine is being used instead of an actual device.

Fingerprint provides both these capabilities and more via its Identification and Smart Signals solutions. Fingerprint accurately recognizes returning visitors so you can detect repeated use of devices, associate a device with a user or payment, and detect suspicious activity based on a multitude of threat signals.

Fingerprint can also provide the “device ID” / “fingerprint” inputs necessary for Mastercard’s First-Party Trust Program and Visa’s Compelling Evidence 3.0, which are programs that give the merchant a chance to dispute an unfair chargeback.

Tutorial: Use Fingerprint to prevent credit card cracking on your payment portal

In this tutorial, we are going to use Fingerprint to protect an e-commerce site using techniques such as bot detection, rate limits, blocked visitors, and more.

We will assume you are running an e-commerce site and accepting card payments on your site. You may be using Stripe to do this or are directly processing credit card transactions on your systems.

We will use NodeJS for our examples. (Fingerprint has libraries for all the popular frameworks and languages, and the implementation will be similar in those, too.)

To get started quickly, let’s use some example code from Stripe that simulates some of the code an e-commerce store might have:

git clone https://github.com/stripe-samples/accept-a-payment/
cd custom-payment-flow/server/node

Create a file .env in the root of the custom-payment-flow/server/node folder and add these settings. Optionally, update the appropriate test account values if you have a Stripe account:

# Stripe API keys - see https://stripe.com/docs/development/quickstart#api-keys
STRIPE_PUBLISHABLE_KEY=pk_test...
STRIPE_SECRET_KEY=sk_test...

# Required to verify signatures in the webhook handler.
# See README on how to use the Stripe CLI to test webhooks
STRIPE_WEBHOOK_SECRET=whsec_...

# Path to front-end implementation. Note: PHP has it's own front end implementation.
STATIC_DIR=../../client/html
DOMAIN=http://localhost:4242

Now, run these commands to get the server up and running:

npm install
npm start

You can now browse to http://localhost:4242 to see the example site, which looks like this:

Clicking the Card link takes you to a self-hosted payment page, that, at the moment, doesn't do any detection of suspicious activity. Let’s use Fingerprint to try to detect credit card cracking as well as fraud in general.

Using Fingerprint bot detection to detect automated tools

The first layer of protection we will add is Bot Detection. Since bots are used by credit card crackers and not by genuine users, this is a good check to deter credit card crackers. In this example, we will block payments when we detect the user is a bot.

Install the Fingerprint library:

npm install @fingerprintjs/fingerprintjs-pro-server-api

Sign up for a free trial, and you can then create a secret API key. Armed with this API key, you can now add the following code to the top of server.js, setting the apiKey value with your key:

const {
  FingerprintJsServerApiClient,
  Region,
} = require('@fingerprintjs/fingerprintjs-pro-server-api')

const client = new FingerprintJsServerApiClient({
  apiKey: '<<Private Api Key>>',
  region: Region.Global
})

The bot detection code will be added to the route create-payment-intent. This code is called when the user clicks Pay. We want to run bot detection when this route is called. To do this, we will add code to the front end for Fingerprint to analyze the browser and device, and code in the backend to get a verdict from the Fingerprint Identification service.

In the server, we need to check for the requestId passed from the client, validate this, and determine if Fingerprint thinks this request is a bot:

app.post('/create-payment-intent', async (req, res) => {
  // New code, that takes the requestId from the client, and verifies it with the
  // Fingerprint service, using the bot-detection results:
  const { paymentMethodType, currency, paymentMethodOptions, requestId } = req.body;

  const event = await client.getEvent(requestId);
  const isBot = event.products.botd.data.bot.result != 'notDetected';

  if (isBot) {
    return res.status(400).send({
      error: {
        message: 'Payment failed',
      },
    });


  }

  // Existing code

  // ...
}

There are some changes to the client; first, we need to load the Fingerprint API:

// Load the library immediately, so it is ready by the time the user clicks Pay
const fpPromise = import('https://fpjscdn.net/v3/<<Public Api Key>>')
  .then(FingerprintJS => FingerprintJS.load())

// Existing code

// ...

Note: You need to replace <<Public Api Key>> with your public API key.

When the user clicks Pay, we then send an identification request to Fingerprint using fp.get(). This is for two reasons: First, we need to indicate that the user has taken action and not just visited the page. Second, we need to get a requestId to be used for server validation.

// Using the Fingerprint library, get a requestId for this session

form.addEventListener('submit', async (e) => {
  e.preventDefault();

  const fp = await fpPromise;
  const result = await fp.get();
  const requestId = result.requestId;

  // Existing code

  // ...

Finally, pass the requestId to the server when making the request.

// Include the requestId with data sent up to the server

        body: JSON.stringify({
          currency: 'usd',
          paymentMethodType: 'card',
          requestId: requestId // <-- Add this line
        }),

The requestId is being sent to your server where you can use your secret API key to get the full identification event. This information includes the visitorId as well as the detection result flagging any bot activity. While the visitorId is returned on the client from fp.get(), you should avoid using it directly and use the requestId to get the full event directly from Fingerprint to thwart any client-side tampering.

You can read more about this here: Protecting from client-side tampering.

Proxying requests to avoid ad blockers

You should also strongly consider proxying requests to Fingerprint through your own domain. This prevents ad blockers from interfering with the operation of the Fingerprint front-end code. We have detailed information on how to do this here: Evading ad blockers with proxy integrations.

Using Fingerprint visitor IDs to enforce rate limits

We can check how many times a visitor has tried to make a transaction (successful or otherwise) in the last 24 hours. If this is above a reasonable threshold, say 5 transactions, then we can block the request or require some other form of verification like a one-time passcode sent via SMS.

Depending on your use case you can tune the limit to fit your needs or enforce a limit only for non-verified users of your site.

To enforce a rate limit, we can record the visitor ID and timestamp for each transaction attempt. Then when the user clicks the Pay button, we check how many transactions have been attempted in the last 24 hours:

// Inside /create-payment-intent handler
// Set up DB connection (using Postgres for this example)
const pgp = require('pg-promise')();
const db = pgp('postgresql://username:password@localhost:5432/database');
const visitorId = event.products.identification.data.visitorId;

// Block requests when more than 5 attempts were made over 24 hours:
let result = await db.any('SELECT COUNT(*) FROM visitor_payment_attempt WHERE visitor_id = $1 AND created_at > NOW() - INTERVAL \'24 HOURS\'', visitorId);

if(result[0].count >= 5) {
  return res.status(400).send({
    error: {
      message: 'Payment failed', // Don't leak specific information about how they were detected
    },
  });
}

const paymentIntent = await stripe.paymentIntents.create(params);

const paymentIntentId = paymentIntent.id;

// Store the attempt:
await db.none('INSERT INTO visitor_payment_attempt (visitor_id, created_at) VALUES($1, $2)', [visitorId, new Date()]);

The credit card cracker’s job is now much harder. They will be blocked after 5 tries in a day and will not be able to test any more cards on your site.

Block known fraudsters with their visitor ID

As seen above, when a visitor clicks the Pay button, we get a payment intent identifier from Stripe. If the visitor then makes a transaction that later becomes a chargeback, Stripe can provide that same payment intent identifier for that chargeback. This alone is somewhat useful, but not enough to identify the fraudster if they try this again.

To solve this using Fingerprint, we can record the visitorId along with the payment intent identifier when a visitor clicks Pay. Later on, when you have a chargeback, you can find out which device and browser was involved and block them, using these steps:

Make a call to Stripe to get the payment intent identifier of a chargeback
Look up the visitorId involved with that payment intent in your database.
Block that visitorId from further transactions on your site.

The code changes we need in our server to store the link between visitorId and payment intent, and check for blocklisted visitors, are as follows:

// Inside /create-payment-intent handler

// ... acquire DB connection ...


const visitorId = event.products.identification.data.visitorId;

// ... other checks ...

// Look up the visitorId from the database against the blacklist, and
// if they are on the list, block them:
let result = await db.any('SELECT * FROM blacklist WHERE visitor_id = $1', visitorId);
if(result.length > 0){
  return res.status(400).send({
    error: {
      message: 'Payment failed', // Don't leak specific information about how they were detected
    },
  });
}

const paymentIntent = await stripe.paymentIntents.create(params);

const paymentIntentId = paymentIntent.id;

// ... other insert statements ...

// Store the paymentIntentId and visitorId for future use and blacklisting:
await db.none('INSERT INTO visitor_payment_intents(visitor_id, payment_intent_id) VALUES($1, $2)', [visitorId, paymentIntentId]);

In addition to recording the payment intent and visitor ID, we can also store their user ID (if logged in), and the email address or physical address they used when making the purchase. We can store information from the Fingerprint API such as IP addresses and geolocation information too.

This data can aid investigations into fraud that may be carried out months after it has occurred.

Key takeaways to prevent credit card cracking

Credit card cracking is an insidious practice that causes a lot of cost and hassle for merchants and credit card companies.

The best defense is layered, taking advantage of the tools provided by payment providers like Stripe, card authorization, multiple-factor authentication, and device intelligence tools like Fingerprint.

To try Fingerprint now, check out our Getting Started Guide, or contact our team to find out more.