Security best practices

Use these guidelines to securely build integrations with the Infobip APIs. They cover authentication, traffic encryption, credential handling, and protection against artificially inflated traffic (AIT).

The guidance here covers the developer and traffic security controls for your integration. Account security (passwords, users and roles, 2FA, account policies, phishing awareness) is covered in Get started. See Security settings, Manage roles, and Account access.

Traffic security

Protect traffic in both directions: the requests you send to Infobip, and the webhooks Infobip sends to your endpoints. This section covers TLS requirements, connection types, and inbound webhook security.

TLS requirements [#tls-requirements-traffic-security]

Infobip requires TLS v1.2 or higher for all API connections. Support for earlier versions was discontinued on July 5, 2021. Requests using a lower TLS version are rejected. If you are unsure which TLS version you are using, or need help upgrading, contact Support.

Connection types [#connection-types-traffic-security]

Always broadcast traffic over an SSL/TLS encrypted connection. Unencrypted HTTP or SMPP connections expose credentials and message content. The following table compares the connection types:

For SSL endpoint details, see SMPP for SMPP SSL endpoints and REST API traffic encryption for HTTP endpoints.

Avoid using GET methods for sending messages. GET parameters are logged in HTTP proxies, browser history, and web server logs, which can expose API keys and message content.

Secure inbound webhooks [#secure-inbound-webhooks-traffic-security]

When Infobip sends data to your endpoints, such as delivery reports and inbound messages, protect those endpoints so only Infobip can reach them:

• Serve them over HTTPS.
• Accept requests only from the IP addresses in the IP address safelist.
• Add authentication settings (HMAC signatures, Basic, or OAuth) and mTLS certificates to your webhook subscriptions. For per-request webhooks, create a standalone notification profile for the URL.

For setup, and how to verify HMAC signatures, see Webhooks.

API authentication and authorization

How you authenticate API requests determines how much damage a leaked credential can do. The following practices limit that exposure.

Use API keys and dedicated API users [#use-api-keys-and-dedicated-api-users-api-authentication-and-authorization]

When broadcasting traffic over HTTP, use an API key rather than user credentials (username and password). API keys can be scoped, rotated, and revoked independently, which reduces the risk from compromised credentials. For SMPP, create a dedicated user for broadcasting traffic and connect over SSL. To create and manage API keys, see Authorization and scopes.

Use separate credentials for API access and web interface access. Keep dedicated users for each purpose:

• API users: Restricted to API access only, enforced through the IP safelist
• Web interface users: Used for web interface access only, not for traffic broadcast

Keeping these separate limits the blast radius if one set of credentials is compromised. It also prevents connectivity issues caused by mixing session-based and API-based access patterns.

Token and API key expiry [#token-and-api-key-expiry-api-authentication-and-authorization]

Use time-constrained API keys or tokens to limit exposure if credentials are leaked:

• IBSSO session tokens: Expire after roughly 60 minutes of inactivity by default. Destroy the session as soon as you no longer need it. See IBSSO token authentication.
• API keys: Sessionless and sent with each request. Set a validity period per API key. The key is rejected once it expires.

Rotate API keys periodically, and immediately if a key is exposed (for example, committed to a repository or shared in plain text). Revoke the compromised key first, then issue a replacement.

IP safelisting [#ip-safelisting-api-authentication-and-authorization]

IP safelisting lets you restrict access to the Infobip platform to a defined list of trusted IP addresses or ranges. Configure it at the level that matches your access pattern:

• User level: Restricts access when a user logs in to the web interface or their credentials are used for traffic broadcast.
• API key level: Restricts access whenever that specific API key is used. Configure it in Developer Tools > API Keys in the web interface, or when creating an API key through the API.

The following formats are supported:

• Single IPs: 192.168.1.1;192.168.1.2;192.168.1.3
• IP range: 192.168.1.0/24

Consider the following when configuring IP safelisting:

• API integrations typically use static IPs or company/ISP ranges, so IP safelisting is straightforward to configure.
• Web interface users may connect from dynamic IPs (home networks, mobile, travel). Account for this when applying user-level restrictions, to avoid locking legitimate users out.

Credential storage

Treat API keys and tokens with the same care as passwords. Never include them in source code, commit them to version control, or share them with third parties, including Infobip staff. The following example shows what to avoid:

Secure storage options [#secure-storage-options-credential-storage]

The following options are listed from most to least secure:

1. Hardware Security Module (HSM): HSMs are tamper-resistant physical devices certified to FIPS 140-2 Level 3. They store secrets and perform cryptographic operations in a dedicated, isolated environment.

2. Load credentials at startup: Request credentials when the application starts and hold them in memory only. This ensures they are never written to disk. Credentials held only in memory are lost on application restart and must be re-entered. The following example shows this approach:

   java

   1@Bean

   2public SensitiveData getSensitiveData() {

   3 Console console = System.console();

   4 SensitiveData data = new SensitiveData();

   5 // SECURE: credential entered at startup and held in memory only

   6 data.setAuthorization(console.readPassword("Input Infobip API authorization: "));

   7 return data;

   8}

3. Encrypted credential store: Store secrets in a verified encrypted keystore and load them at application boot. Encrypt secrets at rest and restrict the decryption key to a specific service account. Use a dedicated secrets management service that authenticates the application before serving credentials.

4. Environment variables: Store the credential in an environment variable and reference it in code. This keeps secrets out of source files and version control. The following example shows this approach:

   java

   1// SECURE: credential read from environment variable

   2.addHeader("Authorization", System.getenv("INFOBIP_API_AUTHORIZATION"))

Risks of not applying safeguards [#risks-of-not-applying-safeguards-credential-storage]

Failing to implement these controls can result in credential or data leakage. Unencrypted connections expose credentials and message content in transit. With unencrypted HTTP and Basic authentication, your username and password are encoded in the Authorization header. They can be intercepted at any node between your network, ISPs, proxy services, and the Infobip platform. Unencrypted SMPP exposes message content and credentials in the same way. In a man-in-the-middle (MITM) attack, credentials and message content can be intercepted between the client network and the Infobip platform.

Credentials are also at risk wherever they are stored or shared in plain text. Credentials stored in plain text, in any digital or analog form, can be read by anyone with access. Credentials shared in plain text over electronic channels, by telephone, or in live discussion can be captured. Credentials hardcoded in source code can be read and misused by any developer, contractor, or third party with repository access. Stale passwords add to the risk: credentials that have not been changed for a long time increase the window of exposure if they leak.

Prevent artificially inflated traffic (AIT) and SMS pumping

AIT, also called SMS pumping, is a form of fraud that targets application flows which automatically trigger message delivery. A common example is a sign-up or verification flow. An attacker automates form submissions with fake phone numbers to generate large volumes of messages that no genuine user requested. Because this traffic originates from your own application, it reaches Infobip as legitimate traffic.

Controls must be implemented in your own web application. To detect and block SMS pumping on the Infobip side as well, see Signals. The following controls are described in SMS terms but apply to any channel where a public-facing flow can trigger paid traffic.

Limit the traffic a flow can trigger [#limit-the-traffic-a-flow-can-trigger-prevent-artificially-inflated-traffic-ait-and-sms-pumping]

Limit the frequency and quantity of SMS messages that can be triggered by a user, account, phone number, IP address, device, or other relevant identifier. Apply rate limits at multiple levels where appropriate.

Rate limiting is a strong first control, but not foolproof. Sophisticated attackers drip traffic at low volumes over time to stay under thresholds. Treat it as one layer among several.

Maintain proper visibility and control over all API endpoints, including legacy, test, debug, staging, and internal deployments. All endpoints that can trigger SMS sending must be authenticated, protected, and rate-limited.

Block automated and forged requests [#block-automated-and-forged-requests-prevent-artificially-inflated-traffic-ait-and-sms-pumping]

Use CAPTCHA solutions (such as reCAPTCHA or hCaptcha) to make automated abuse more difficult. Consider additional bot-mitigation methods such as behavioral analysis or context-specific verification steps, since some CAPTCHA challenges can be bypassed. Use anti-CSRF tokens for sensitive HTTP requests to prevent unauthorized actions performed through the authenticated session of a victim. Generate a new token for each request rather than for each session, which shortens the time an attacker has to use it.

Secure the application [#secure-the-application-prevent-artificially-inflated-traffic-ait-and-sms-pumping]

Define what input is allowed for each field and validate it accordingly. Sanitize and encode untrusted input where necessary. To reduce the risk of injection attacks, use secure database interaction methods such as prepared statements or parameterized queries.

To prevent Insecure Direct Object Reference (IDOR), verify that a user is authorized to access any requested object or resource. Avoid exposing predictable internal identifiers, such as sequential IDs, which are easy to guess. Use non-sequential identifiers, such as hashes, and enforce authorization checks on every request.

Use HTTPS instead of HTTP. Disable obsolete protocols and weak cipher suites. Use TLS 1.2 or TLS 1.3 instead of SSL 2.0/3.0, TLS 1.0, and TLS 1.1. Application cookies must include at least the Secure and HttpOnly attributes. Add the SameSite attribute to reduce the risk of cross-origin information leakage. Use headers such as X-Frame-Options, Strict-Transport-Security, and Content-Security-Policy for additional protection.

Log authentication events, registration attempts, password or API key changes, access denials, input validation failures, and unusual SMS-triggering activity. Protect logs in transit and at rest, and exclude sensitive data such as plain text credentials from logs.

Flooding filter (DCL)

The flooding filter, also called DCL (Destination Counter Limitator), is a platform-level anti-flooding mechanism enabled by default for every account. It silently rejects messages (no HTTP 429) when a destination number receives too many messages within 60 minutes. Rejected messages are not charged. For thresholds, integration impact, and how to adjust the limits, see Flooding filter (DCL).