Real-Time Validation APIs: How to Prevent Theft in the New Year

When it comes to preventing bad data from entering your CRM, real-time validation can make a world of difference. But did you know it can also put your company at risk?

Theft is a common problem with real-time validation APIs. Preparing your business to deal with theft can help you protect your data, save money, and prevent future attacks.

While you’ve been focused on growing your mailing list and maximizing revenue this holiday season, there’s a chance you may have left your company vulnerable to theft.

Let’s dive deeper into real-time validation APIs, the challenges they present, and steps you can take to protect your business in the new year.

What is real-time validation?

Say a customer clicks on one of the CTAs in your email or social media campaign. You’re offering to take 20 percent off their purchase in exchange for a monthly newsletter. Sounds like a good offer! So, they decide to add their email address to the sign-up form.

Except they don’t. They enter a random email address hoping to dodge their end of the bargain. Or perhaps they type in their real email address, but accidentally leave a typo. Either way, when they go to submit, they receive a gentle feedback message: “It looks like your email address may not be valid. Can you check again?”

You just made sure one customer acts in good faith, and the other gracefully recovers from a genuine mistake. That’s real-time validation.

Real-time validation works by performing a validation check (using a third-party validation API) on information like email addresses, mailing addresses, and phone numbers before a customer submits a form. It can be done for newsletter sign-ups, purchase forms, registration forms, or any other kind of lead-generating input.

Real-time validation keeps bad information out of your contact lists by preventing it from getting there in the first place. This is important because routinely sending to invalid addresses can hurt your reputation with mailbox providers and cause deliverability issues.

The challenge with real-time validation APIs

This all sounds great. But unfortunately, hackers think so, too.

Theft is one of the biggest problems you’ll face when it comes to real-time validation APIs. Depending on how well your engineering team is resourced, it can be hard to anticipate. But if overlooked altogether, it can quickly become a serious business risk.

Here are two of the main types of theft you need to look out for:

Validation theft

Putting validation on a public-facing form means that anyone has access to it. This is good, right?

Yes and no. It means bad actors can access it, as well. These folks would like their mailing lists validated too. If they discover your form can do that, they can write automated scripts to repeatedly plug their email addresses into your form, trigger the validation step, and gather the results. Simply put, they’re performing validations on your dime.

These kinds of attacks can cost unsuspecting businesses tens of thousands of dollars in a matter of minutes. Experienced engineering teams can (and should) guard against this kind of attack, but it requires additional planning and development hours that may either not be considered at the outset of an integration project, or simply be unavailable due to resources.

API key theft

Validation services will give you an API key with your account that allows you to access its API. Whoever holds this key has access to the services you’re paying for. The API key is also necessary for real-time validation in your forms, so it needs to be included in your code.

Loading a web page is like baking a cake. At first, the entire recipe (including the secret ingredient, or in this case, the API key) is known only to the baker. But once it’s baked, many of the ingredients are fixed and visible to anyone.

The same is true with the web. Just open any browser, load a page, open the code inspector, and you’ll see the visible ingredients (or client-facing code). The viewable parts of your code are usually innocuous. But if your engineering team decides to take the easy route and include the API key in the client-facing code, any bad actor can come along, grab the key, and use the validation credits you paid for.

Experienced engineering teams can guard against this by creating a way for the API key to remain secret (in the secret part of the recipe, or back-end code). But this can easily be overlooked and requires more work to implement in a safe and speedy way.

The stakes are higher during high-volume selling periods

The opportunity to grow mailing lists and generate revenue is huge during high-volume selling periods like the holiday season, the start of the new year, and even Valentine’s Day. However, these are also perfect times for bad actors looking for unprotected forms and API keys to prey on your business.

Enter the public key

A standard API key is a private key. Efforts to maintain that privacy require more time, skill, and higher development costs (if you have the resources for that).

A good solution is one that doesn’t require privacy: a public API key.

Think of private and public keys like the double doors you use to enter a department store (if you still do that sort of thing). Both doors exist to protect the interior of the store from inclement weather. Whatever is outside gets captured in the space between the first door (the public key) and the second door (the private key).

Let’s see how they tackle our two theft problems:

• Validation theft: You cannot prevent a bad actor from visiting your site and attempting to hijack your form, but you can mitigate the risk. The beauty of using a public key (or the “exterior door”) is that you control the space in between.

Since validation calls must enter that space, you get to decide what to do with them. By limiting the number of times a validation call can be made by a given user (per minute or per second), you greatly limit the damage a hijacker can do. You also present a much less attractive target. If you have the resources, your engineering team can build out custom functionality to do this, or you could let a service that provides throttling via public API keys do it for you.

• API key theft: Because public keys are meant to be used in client-facing code, you don’t need to develop sophisticated methods to keep it secret. You can literally just leave it exposed, because you mediate the space between the doors.

You can restrict validation calls by their originating domain, which means you can reject any API calls that come from domains you are not associated with. So, even if a bad actor steals the key, it will be of much less value to them. Any implementation of public keys (whether your own custom solution or a validation service) should use at least two factors to mediate the requests that come in through your doors. Rate throttling and domain whitelisting are a good start.

The best part of using a validation service that supports public keys is you can stop worrying about development time and resources. The integration work for a validation API with a public key is far simpler (thus faster), since many of the questions surrounding security are worked out ahead of time.

Conclusion

The new year will present many opportunities to grow your mailing list, so it’s important to ensure only valid data enters your CRM. Be sure to prevent bad actors from capitalizing on your validation API by using a validation service that supports public keys.

BriteVerify, for example, can help you mitigate the risk of API theft while still ensuring contacts are entering accurate data into your web forms.

To learn more, schedule a demo with us today.