Fraud Prevention¶
In the GatewayAPI term, we take the challenge of fraud prevention very seriously and to everything we can to prevent fraud and malicious use as well as we can. So like many other SMS gateways, we filter the messages that travel through our systems, but as our systems are used by many enterprises, we can only have a very general suite of filtering. As a result of this it is also possible for you to check messages generated by your systems before submitting them. A general advice is that you know your business best - your own filtering can be tailored exactly to your needs.
Our Filter Systems¶
An Ever Evolving Threat
Since the patterns of abuse are always changing, we cannot allow ourselves to be satisfied with our current filtering.
Therefore, we are always inspecting samples of the messages that we process to learn how they can be used as an attack vector for phishing and spam. What we learn from inspecting the traffic, we then use to improve our filters and create new ones.
Trial account¶
By default, all new accounts will be in trial mode, which will expire after 30 days unless activated. While your account is in trial mode, strict rules and limitations may apply due to security concerns. Read more about this in our Help Center
Sender ID Filtering¶
The sender of each SMS is matched against a blocklist, with exemptions for certain accounts that are known to use those senders.
Link Filtering¶
We extract links in SMS messages that we receive and match them against a list of allowed links for that given account, which means that all links have to be approved in advance by our support team.
Country Filtering¶
We match the recipient number for each message to a country, and it is possible to restrict what countries your account can send messages to via the dashboard.
Your Filter Systems¶
Alerting¶
The softest approach to fraud prevention is not to actually reject/filter any messages, but instead have some kind of monitoring system that can notify you when something unusual is happening. Examples of unusual activity could be:
- When an unusual amount of messages are being generated.
- When messages are being generated at an unusual time of the day/week.
- When the message distribution by country is different from the norm.
Country Filtering¶
Provided that the messages are only meant to be sent to certain countries, it can be possible to outright reject messages to some countries. However, some flexibility can be built-in so the business product does not reject users with phone numbers from foreign countries (such as travelers). This can be something like a system that can detect anomalies in which countries messages are currently being sent to based on the historical data.
The relationship between mobile phone number prefixes and countries is not strictly 1-1, but it can be good enough for these purposes. There are various datasets that can inform about this, but the wikipedia page about prefixes by country strikes a good compromise between ease of use and up to date information.
Throttling¶
Depending on the business case it might be possible to impose a limit on how many messages can be sent per time unit (such as seconds or minutes). This can limit the impact of certain types of attacks.
This can even be combined with country filtering where messages to certain countries are throttled. This pairs well with a regionalized business case where the vast majority of messages are sent to a well defined set of countries, and only smaller amounts are sent to other countries.
Other Measures¶
We also recommend making sure that there are as few profiles with access to your GatewayAPI account as possible, and that old accounts are quickly removed or possibly deleted.
And as an extra layer of security, you can configure your account to only allow requests from certain IPs via the dashboard. This makes it impossible for servers outside of your network to submit messages on your behalf, even if your authentication credentials somehow got leaked.
Lastly, if your account is post paid, we recommend making sure your credit limit is set to a reasonable limit, as that is the only limit on how many messages a hijacker can send if your systems are compromised, either directly or indirectly.