How to fight spam in concrete5
Dealing with spam can be very annoying and time consuming. In this post I try to outline a few solutions for concrete5 users.
There are a few strategies / mechanisms in concrete5 you can use:
- Spam Control
- IP Blocking
- Captcha Protection
- Token Validation
- Honey Pots
1. Spam Control
If you go to System & Settings > Permissions & Access > Spam Control you can select an anti-spam library. When an Express Form is submitted, for example, the submitted data is concatenated as a string and then passed to a spam library. If the library detects spam, it'll throw an error. With a standard installation however, no spam libraries are installed (as of 6th Sept '18). It is possible to add your own spam library or you'd install an add-on. So far I have found one (paid) integration in the marketplace. It's called Akismetty and it integrates with Akismet, a well known service for WordPress users. I have no affiliation with the add-on author or the service.
2. IP Blocking
Your form integration could check whether the user's IP address is blocked. If the visitor tries to submit spam, you'd add it to the (temporary) list of blocked IP addresses. If you want to do this, look for the createIPBan method in the IPService class. You can view the IP blacklist via System & Settings > Permissions & Access > IP Blacklist.
3. Captcha Protection
Captcha stands for "Completely Automated Public Turing test to tell Computers and Humans Apart" and that's exactly what it aims to do. You're probably familiar with the 'puzzles' you have to solve before submitting a form. By default, concrete5 comes with the 'SecurImage' captcha library. It simply renders an image, and the visitor has to enter the pictured characters in a text box. It looks pretty ugly. If you are looking for an alternative, you might want to take a look at the free ExchangeCore reCAPTCHA add-on. If you are worried about privacy, be aware because reCACPTCHA uses Google. It's also possible to write your own implementation of course. You can easily implement the CaptchaInterface and register the library via the src/Captcha/Library.php class.
4. Token Validation
It's a best practice to use CSRF tokens in all your forms. That way, one can't just submit all kinds of data to your endpoint / form processor. It's seen as a security flaw if your forms don't work with CSRF tokens. Read more about concrete5 form tokens if you haven't already.
5. Honey Pots
If you have created your own form / form handler, you can add a dummy field to your form, for example a hidden field called 'firstName'. In your form handler you can check whether the field was submitted with any data, if so, you're dealing with a 'robot'. Humans wouldn't be able to see the field and they wouldn't have entered any text to it. An alternative to a hidden field can be a normal text field that is positioned outside the viewport with e.g. 'position: absolute; left: -5000px;'.
If a form is submitted within for example 1 second, the submitter is probably not a human. You'd add a check in your form handler that subtracts the timestamp from a hidden field (or session timestamp) with the time the data was submitted. If the threshold is too low, you'd block the submission.
I hope these solutions make sense to you. If you have suggestions, feel free to reach out to me via the feedback button.