For many people, the word “spam” invokes a special kind of revulsion. Marketers know a whole other side of spam due to the dreaded Form Spam. That’s right, if you are a Marketer, garbage form submissions have likely been a part of your career at one time or another. Well, you’re in luck! This post will help you navigate simple to complex solutions in Oracle Eloqua to manage or eliminate spam submissions on your inbound forms.
Oracle Eloqua-Only Solutions
A lot can be achieved directly within Eloqua. Oracle has made strides over the last year or so to make forms more robust with updates to validation. You may have noticed new defaults on text field validation with a range of 0-35 characters and URLs being disallowed by default.
You can expect more to come in future releases directly within the form editor. While these validation updates have helped by building in some best practices, there is more that can be done.
Another way in which we can reduce spam that is currently available isn’t actually found within forms. If you look under System Settings > Security > Whitelisting > Domain you will find 4 tabs. We’re most interested in External Form Integration and Form Redirect Processing here.
- External Form Integration essentially sets Eloqua to only accept form submissions from domains you own or have explicitly allowed to send data to your forms.
- Form Redirect Processing ensures that your Contacts are only being sent to blessed domains, and not anywhere that is potentially dangerous. Consider these lists carefully before implementing or adding to them.
- Place a hidden field on the form that expects an answer to a question, such as, “What color is the sky?
- If any other value comes through on the form submission you can then reject it using form processing conditions.
More Advanced Solutions
Many businesses host forms on their website, outside of Oracle Eloqua. As mentioned before, filling out the External Form Integration table can help better lock down spam submissions. Here are some other ideas to consider.
- Funnel all submissions through your CMS. Your CMS can become a choke point where all submissions can be verified before being relayed (or not) to Eloqua. This allows you to create a custom solution specific to your needs/types of attacks you are seeing.
- Disallow forms on Eloqua Landing Pages. Move all forms to your CMS to enable an intermediate layer of validation between submissions and Eloqua.
- Add a hidden token. Within the CMS, give your users the ability to provide a secret token for each form. This value would never be shared outside of your CMS and the Eloqua form. Within Eloqua, add a hidden field to capture the token. Any submissions that do not have the right value can be rejected. If the token is somehow discovered, it can easily be changed.
- Strengthen Honeypot. Like the hidden token, add a field for your website users to populate themselves so that each form can have a different Honeypot answer that can be changed at a moment’s notice, if needed.
- Randomly generate hidden token and Honeypot values. Have the CMS provide a value that can be copied and pasted into the Eloqua form conditions.
- Create an email domain blacklist. By funneling submissions through your CMS, you can leverage the database and scripting language to do more powerful introspection on what data each submission contains. Create a list of blocked domains (and keep updating it!) and automatically reject these types of submissions.
- Create an IP blacklist. Likewise, create a list of IPs or IP ranges that are known offenders.
- Disallow submissions within a given timeframe. Is someone submitting forms faster than humanly possible? Don’t allow them through to Eloqua.
- Send them a success message anyway. Why let your attackers know they failed? Let them think their efforts are a success and they may not search for other ways of making submissions.
- Create logs. Data can be saved in the CMS and in Custom Data Objects within Eloqua. Later analysis can reveal patterns that may not be immediately apparent.
- Add CAPTCHA. CAPTCHA should be weighed against it being a barrier to entry for your actual website visitors. If it over-complicates a form, consider not using it. Consider that CAPTCHAS can and are broken by people who are paid by the submission, not necessarily by bots. CAPTCHA will need to be implemented in your CMS.
Reducing spam submissions can be a cat-and-mouse kind of game. Attackers don’t need to be outsmarted, but the solutions implemented have to be just hard enough to make them give up. So, start simple and work your way up if spam submissions don’t reduce over time. If a form is compromised, have a plan in place to take it offline: change the HTML name in Eloqua, remove or unpublish the form from your site, and analyze the data. To learn more about implementing any of the solutions I have outlined, contact us today and let’s harden your forms and keep those bots away!
Latest posts by Jesse Nobbe (see all)
- Organizing Eloqua Email Groups for Multiple Business Units - January 7, 2021
- 5 Data Model Considerations When Migrating to Oracle Eloqua - November 19, 2020
- The Shift in Browsers Privacy – What Heightened Internet Privacy Fears Means for Digital Marketers - November 10, 2020