SMS and OTP bombing are attacks in which a bot repeatedly triggers an OTP or sign-up form on your website in order to generate SMS in bulk. Typical motives are harassment of third parties ("SMS flood" on a target number), draining your balance and above all IRSF fraud (International Revenue Share Fraud), where attackers send SMS to expensive international premium numbers from which they earn a share themselves.
Auf einen Blick
- The trigger almost always sits in the OTP form: captcha, rate limit and cooldown are mandatory.
- In seven, the country restriction is the most important way to limit damage.
- Enforcing HMAC request signing plus an IP whitelist renders a leaked API key worthless.
- A subaccount only works as a cap if Auto Top-up is disabled.
- 2FA, separate API keys per service and a low balance alert are part of the basic setup.
No single feature protects against this class of attack. Only layered protection is effective: first in your application, then in your seven account.
Where the actual hole is
In most bombing cases the OTP form is unprotected: no captcha, no rate limit, no cooldown. The attacker calls the send endpoint hundreds or thousands of times per minute, and every call generates a real SMS. seven can limit the damage, but you have to close the trigger in your application.
Protective measures in your application
These points belong in your frontend and backend, not at seven:
Captcha in front of the send button. reCAPTCHA, hCaptcha, Cloudflare Turnstile or comparable bot detection. This is the most effective single measure.
Rate limit per IP, per session and per recipient number. Example: a maximum of 3 OTPs per 10 minutes per mobile number and a maximum of 10 OTPs per hour per IP.
Cooldown between resend clicks. First resend after 60 seconds, then exponential backoff (2, 4, 8 minutes).
Number pre-validation. Check the format and the network operator via Lookup before you trigger the SMS. This filters out invalid numbers and exotic premium destinations before any costs arise.
Honeypot fields and behavioural analysis. Log and block hidden form fields being filled, unusually fast submits and atypical user agents.
Protective measures in your seven account
These measures cap the damage in case the application layer is breached after all.
Enable country restrictions
By far the most important lever against IRSF. If your OTP service only serves customers in a few countries, block everything else. Premium number attacks then come to nothing because seven does not deliver the SMS in the first place.
Configure this under Settings > Messages > Country restrictions. For details see Geographic restrictions.
Tipp
Set "Rest" to not allowed and only add the destination countries you really need as allowed. This is a whitelist and blocks all exotic premium destinations.
Enable and enforce request signing
seven supports HMAC-SHA256 request signing for the REST API. Every API request can be signed with a separate signing key that is issued independently of the API key. A stolen API key alone is then useless, provided you enable signature enforcement.
How it works:
Three headers accompany the request:
X-Signature,X-Timestamp,X-Nonce.HMAC-SHA256 is used to sign a string made up of timestamp, nonce, HTTP method, full URL and MD5 hash of the body (separated by line breaks).
The timestamp may be at most 30 seconds old (replay protection). The nonce is unique per request.
Configure the signing key under Developer > Settings. In the same area you enable signature enforcement so that unsigned or incorrectly signed requests are rejected.
Full documentation including Bash and PHP examples: docs.seven.io/en/rest-api/signing.
Wichtig
Store the signing key separately from the API key, ideally in a secrets manager (e.g. AWS Secrets Manager, HashiCorp Vault). If both sit next to each other in the same .env, the protective effect is gone.
Server IP whitelist for the API
In addition to request signing, restrict API access to known source IPs: only requests from your app server IPs are accepted, all other requests are rejected with error 903. This also stops attacks in which the signing key and the API key leak together.
Configure this under Developer > Settings > REST API. For details see Whitelist for accessing the API.
A separate API key per service
Do not use the same key for marketing campaigns, transactional SMS and OTP. One key per service means that a single leaked key can be deactivated immediately without interrupting other sending channels. See Where do I find my API key and Deactivation of unused API keys.
Subaccount only as a hard cap, not with active Auto Top-up
A subaccount for the OTP service separates balance and reporting. However, it only works as a damage cap if Auto Top-up is disabled and you fund it manually. Otherwise a low threshold simply leads to more frequent top-ups, and the total damage is the same or higher.
Achtung
Auto Top-up on an OTP subaccount cancels out the cap effect. If you want a hard limit, disable Auto Top-up and top up manually.
Recommended setup:
a dedicated subaccount "OTP" with its own API key
Auto Top-up disabled
manual top-up with a fixed monthly budget (e.g. 50 EUR)
once the subaccount is empty, sending stops automatically
Details on the setup: Subaccounts.
Low balance alert to several recipients
An unusual wave of messages inevitably leads to a rapidly falling balance. Set a threshold and at least two recipient addresses (tech and billing) so that the alert still arrives when one person is on holiday. See Notification of low balance.
Account security
Enforce 2FA for all account members so that a stolen password is not enough. See Two-factor authentication (2FA) and Enforce two-factor authentication.
IP whitelist for login in addition to the API whitelist if you work from fixed office IPs. See IP whitelist for login.
Deactivate unused API keys and review them regularly.
If an attack is already under way
Rotate or deactivate the API key immediately in the developer settings. This stops any further sending at once.
Tighten the country restrictions and block all non-target countries.
Contact support at support@seven.io with your account ID and the time window. We help you analyse the sending patterns and support you in containing the attack. Please note: costs for SMS that were triggered by an unprotected customer application are generally not refunded.
Secure the application side before you re-enable sending. Add a captcha, enable rate limiting, analyse the logs.
Our support team will be happy to assist you with specific incidents.