Security & Responsible Disclosure

1. At a glance

We use layered security measures, including HTTPS, strong password hashing, hashed API keys, role-based staff access and audit logs. No system is perfectly secure.
You can help protect your account with a strong password, by keeping API keys secret and by using an IP allowlist.
If you find a security vulnerability, please report it privately to us and give us reasonable time to fix it before you disclose it.
Test only against your own accounts. Do not access other people's data, disrupt the service or send SMS to third parties.
We do not currently offer bug bounty payments.

2. How we protect the platform

Our security measures include:

Encryption in transit: the website, dashboard and API are served over HTTPS.
Passwords: stored only as Argon2 hashes.
Codes and keys: one-time codes (OTP) and API keys are stored only in hashed form. An API key is shown once, when you create it.
Encrypted secrets: sensitive stored values, such as SMS provider credentials and email job data, are encrypted.
Sessions: session cookies are HttpOnly and Secure, and sessions expire after a period of inactivity.
Staff access: role-based access on a least-privilege basis. Viewing identity documents needs a separate permission, and every view is logged.
Audit logs: significant actions by customers and staff are recorded in append-only logs.
Abuse controls: rate limiting, CAPTCHA, content and link checks, and risk monitoring.
Private documents: KYC and business documents have no public links and open only through short-lived signed links.
Signed webhooks: webhook requests we send you are signed, so you can check they came from us.

No method of transmission or storage is completely secure, and we cannot guarantee that information will never be accessed, disclosed or altered without authorization. Our Privacy Policy explains how we handle personal information.

3. How to protect your account

Use a strong, unique password that you do not use on any other website.
Keep API keys secret. Never put them in websites, mobile apps, public code repositories or messages. Store them only on your servers.
Use an IP allowlist on API keys, so a key works only from your own servers.
Revoke keys you no longer use, or that may have been exposed, and create new ones.
Verify webhook signatures before trusting webhook data.
Sign out on shared devices.
Watch for phishing. SMSGELY will never ask for your password, OTP, API key, or bKash, Nagad or Rocket PIN.
Check your account activity and contact Support at once if you notice something unexpected.

4. Reporting a vulnerability

If you believe you have found a security vulnerability in SMSGELY, please report it to the security contact shown on this page. If none is shown, use our Contact page, or Support in your dashboard, and say that your message is a security report.

Please include:

a description of the vulnerability and its possible impact;
the affected URL, API endpoint or feature;
clear steps to reproduce it, with any proof-of-concept, screenshots or requests needed;
the date and time of your testing, and any test account you used; and
how we can contact you.

Please do not include other people's personal information in your report. Keep the details confidential until we have resolved the issue.

To report spam, phishing or fraud sent through SMSGELY, which is not a security vulnerability in our platform, use our Report abuse page instead. See our Abuse Reporting Policy.

5. Our commitments

When you report a vulnerability in good faith and follow this policy, we will:

acknowledge your report;
investigate it and work to fix confirmed issues within a reasonable time, based on severity;
keep you informed of our progress where we can; and
with your permission, thank you publicly once the issue is fixed.

We will not pursue legal action against you for good-faith security research that follows the rules in section 6. This does not cover activity that breaks those rules, harms our customers or the service, or breaks the law, and we cannot bind third parties such as our hosting or SMS providers.

6. Rules for security research

When testing, you must:

use only your own accounts, and never access, modify or delete other customers' data;
stop at once and report to us if you come across personal information or other customers' data, and do not keep, copy or share it;
not run destructive tests, or tests that could damage data or degrade the service;
not carry out denial-of-service or load testing;
not use automated high-volume scanning against the service;
not attempt brute force or credential stuffing;
not use social engineering or phishing against our staff or customers;
not attempt physical attacks on our offices, staff or providers;
not send spam or SMS to third parties, or use the service to message anyone other than your own test numbers; and
give us reasonable time to fix the issue before disclosing it publicly, and agree the timing with us.

You must also comply with all applicable laws.

7. Out of scope

The following are generally out of scope, unless you can show a real security impact:

missing security headers or best-practice settings with no demonstrated impact;
self-XSS, or issues that need the victim to paste code into their own browser;
rate-limiting issues on non-sensitive endpoints;
reports from automated scanners without proof of a working vulnerability;
clickjacking on pages with no sensitive actions;
issues that require a compromised device or physical access to a user's device;
vulnerabilities in third-party services we use, which should be reported to those providers; and
spam or phishing messages sent through SMSGELY (please use Report abuse).

8. No bug bounty

We do not currently offer payments or rewards for vulnerability reports. Reporting a vulnerability does not create any contract or entitle you to payment.

9. Security incidents

If we become aware of a security incident affecting personal information, we will investigate, contain it, take steps to prevent it happening again, and notify affected customers and the relevant authorities as required by applicable law.

10. Changes to this policy

Each version of this policy has a version number and an effective date, shown on this page.

This policy is published in English and Bangla. If the two versions conflict, the version designated by SMSGELY after legal review applies.

11. Important notice

SMSGELY provides messaging infrastructure and related technology services. Customers remain responsible for message content, recipient lists, recipient consent, sender identity and authorization, campaign legality, applicable marketing, telecom and data-protection obligations, and all applicable laws.

SMSGELY does not authorize unlawful use of its service. SMSGELY operates subject to applicable laws, regulations, telecom-provider requirements and contractual restrictions.