Why this keeps happening
Database exposure is not a sophisticated attack. It is a configuration mistake - and it is endemic in the Nigerian startup ecosystem. The pattern repeats: a developer provisions a database during a late-night sprint, copies a configuration snippet from StackOverflow or a Medium tutorial, skips the authentication setup because "we will add that later," and pushes to production. Later never arrives.
Shodan, the search engine for internet-connected devices, indexes thousands of exposed databases in Nigerian IP ranges. In 2024, security researchers identified over 800 MongoDB instances, 400 Redis instances, and 200 Elasticsearch clusters exposed on Nigerian hosting providers and cloud accounts registered to Nigerian companies. Many of these contained financial data, personal identification records, and internal application secrets.
The cost is not theoretical. When a ransomware bot finds your exposed MongoDB, it copies your data, wipes the database, and leaves a ransom note demanding Bitcoin. Even if you pay, the data has already been exfiltrated. Under the NDPA, you are now looking at mandatory breach notification, potential fines of up to 2% of annual gross revenue, and the cascading costs of a data breach.
1. MongoDB with no authentication enabled
MongoDB is the most commonly exposed database in the Nigerian startup ecosystem, largely because it is the most commonly used NoSQL database for fintech MVPs and early-stage products.
How it happens
MongoDB versions prior to 6.0 ship with authentication disabled by default. The default configuration binds to all network interfaces (0.0.0.0), meaning if the server has a public IP address, the database is accessible from anywhere on the internet. A developer installs MongoDB, starts it with default settings, connects their application, and never enables the --auth flag or configures users in the admin database. The application works perfectly - and so does anyone else who connects to port 27017.
How to check
From a machine outside your network (not from the server itself), run: mongosh --host YOUR_PUBLIC_IP --port 27017. If you get a connection and can run show dbs without being prompted for credentials, your database is exposed. Alternatively, search Shodan for your IP address or domain - if port 27017 appears in the results with MongoDB identified as the service, it is indexed and visible to every scanner on the internet.
How to fix it immediately
- Enable authentication: Create an admin user with
db.createUser()in the admin database, then restart MongoDB with the--authflag or setauthorization: enabledin yourmongod.conf. - Bind to localhost: Set
bindIp: 127.0.0.1inmongod.conf. Your application connects locally; nothing else needs direct access. - Firewall the port: Block port 27017 from all external traffic at the OS firewall (iptables/ufw) and cloud security group level.
- Use a connection string with credentials: Update your application's connection string to include the username and password. Store the connection string in a secrets manager, not in your source code or .env files committed to Git.
Cost of this exposure: A single exposed MongoDB instance containing KYC and BVN data for 50,000 users can result in NDPA fines of ₦10 million or more, class action legal costs exceeding ₦25 million, and customer churn that destroys years of growth.
2. Redis instances bound to 0.0.0.0 with no password
Redis is used for caching, session storage, and queuing across Nigerian fintech stacks. It is fast, simple, and - by default - completely unsecured.
How it happens
Redis ships with no password (the requirepass directive is commented out) and, on many installations, binds to all interfaces. Developers deploy it for caching or as a Celery/BullMQ broker and never think about access control because "it is just a cache." But Redis often contains session tokens, OTP codes, rate-limiting counters, and cached user data. An attacker who connects to your Redis can steal active sessions, bypass rate limits, and in some configurations, write arbitrary files to your server's filesystem using the CONFIG SET command.
How to check
From an external machine: redis-cli -h YOUR_PUBLIC_IP -p 6379 ping. If you receive PONG without any authentication error, your Redis is open to the world. Check Shodan for your IP range filtered by port 6379.
How to fix it immediately
- Set a password: Add
requirepass YOUR_STRONG_PASSWORDtoredis.confand restart. Use a 32-character minimum random string. - Bind to localhost: Set
bind 127.0.0.1inredis.conf. If your application server is on a different machine, use a private network interface only. - Disable dangerous commands: Rename or disable
CONFIG,FLUSHALL,FLUSHDB,DEBUG, andSHUTDOWNusing therename-commanddirective. - Enable TLS: Redis 6+ supports TLS natively. Enable it for any connections that traverse a network, even a private one.
Cost of this exposure: An exposed Redis containing active session tokens allows an attacker to hijack logged-in user sessions. For a payment platform processing ₦500 million monthly, even a brief session hijacking campaign can result in direct financial losses exceeding ₦20 million before detection.
OTP codes cached in exposed Redis
During a penetration test for a Nigerian lending platform, we discovered their Redis instance was bound to 0.0.0.0 on port 6379 with no password. The instance contained active OTP codes for password resets and transaction authorisations, cached for 10 minutes each. An attacker could connect, read the OTP for any user, and authorise transactions on their behalf. The fix took 15 minutes. The exposure had been live for 14 months.
3. PostgreSQL listening on all interfaces with weak authentication
PostgreSQL is the production database of choice for many Nigerian fintechs that have moved past the MVP stage. Its exposure pattern is subtler than MongoDB's but equally dangerous.
How it happens
PostgreSQL's security depends on two configuration files: postgresql.conf (which controls what interfaces the server listens on) and pg_hba.conf (which controls who can authenticate and how). The common mistake is setting listen_addresses = '*' in postgresql.conf to allow the application server to connect over the network, then adding a permissive rule in pg_hba.conf like host all all 0.0.0.0/0 md5 (accept password auth from any IP) - or worse, host all all 0.0.0.0/0 trust (no password required from any IP).
How to check
From an external machine: psql -h YOUR_PUBLIC_IP -U postgres -d postgres. If you connect without being blocked by a firewall, the port is open. If you connect without a password prompt (trust authentication), you have full unrestricted access. Scan your IP on Shodan for port 5432. Review your pg_hba.conf and PostgreSQL production hardening settings directly.
How to fix it immediately
- Restrict listen_addresses: Set
listen_addresses = 'localhost'unless your application requires network access, in which case use the private network interface IP only. - Lock down pg_hba.conf: Remove any line with
0.0.0.0/0. Add specific CIDR blocks for your application servers only. Never use thetrustmethod for any network-accessible connection. - Use scram-sha-256: Set
password_encryption = scram-sha-256inpostgresql.confand updatepg_hba.confto usescram-sha-256instead ofmd5. - Enforce SSL: Set
ssl = onand require it inpg_hba.confwithhostsslrules instead ofhost.
Cost of this exposure: PostgreSQL is typically the primary transactional database. Full access means the attacker can read, modify, and delete every record - account balances, transaction histories, user credentials. A confirmed breach of a PostgreSQL database holding financial records triggers mandatory CBN notification and potential enforcement action.
Not sure what is exposed in your infrastructure? A vulnerability assessment scans your entire attack surface - databases, APIs, cloud configurations - and tells you exactly what is open.
Get a Vulnerability Assessment4. Firebase Realtime Database with overly permissive rules
Firebase is the go-to backend for Nigerian startups building MVPs quickly - mobile banking prototypes, lending apps, agent network platforms. The speed-to-market advantage comes with a dangerous default.
How it happens
During development, teams set Firebase Realtime Database security rules to allow unrestricted read and write access. The rules file looks like this: the "rules" object with ".read" set to true and ".write" set to true. Firebase even warns you in the console that these rules are insecure. But the warning gets dismissed during the launch rush, and the permissive rules ship to production. Now anyone with your Firebase project URL (which is embedded in your mobile app's source code) can read and write every record in your database.
How to check
Open a browser and navigate to https://YOUR-PROJECT-ID.firebaseio.com/.json. If you see your entire database contents rendered as JSON, your rules are wide open. You can also check the Firebase Console under Realtime Database, then Rules, and inspect the current ruleset. Any rule that sets .read or .write to true at the root level without conditions is a critical vulnerability.
How to fix it immediately
- Set default deny: Change root rules to ".read": false and ".write": false. Then add specific path-level rules that grant access only to authenticated users accessing their own data.
- Use authentication-based rules: Require Firebase Auth and restrict access per user: ".read": "auth != null && auth.uid == $uid". This ensures users can only read their own records.
- Validate writes: Add validation rules that enforce data types, string lengths, and required fields at the database level.
- Audit existing data: If the rules were permissive in production, assume the data has been accessed. Check Firebase usage logs for unexpected read/write patterns from unknown origins.
Cost of this exposure: An exposed Firebase database for a lending app with 30,000 users - containing loan applications, income data, employer details, BVN numbers, and repayment histories - can trigger NDPA fines of ₦10 million, legal liability from exposed borrowers, and complete destruction of the product's credibility in a market where security is a competitive differentiator.
5. AWS S3 buckets with public ACL
S3 buckets are the de facto storage layer for Nigerian fintechs - KYC selfies, utility bills, government ID scans, transaction receipts, audit logs. When an S3 bucket is publicly accessible, all of that data is one URL away from anyone on the internet.
How it happens
A developer creates an S3 bucket, sets the ACL to "public-read" because the application needs to serve some files (profile images, receipts), and does not realise that the setting applies to every object in the bucket - including the KYC folder containing passport photographs and BVN verification documents. Or they use an S3 bucket policy that grants s3:GetObject to principal * (everyone). AWS now blocks public access by default on new buckets, but older buckets created before this change (and buckets where the block was manually removed) remain exposed.
How to check
Log in to the AWS Console, navigate to S3, and check each bucket. Look for the "Publicly accessible" warning label. Alternatively, use the AWS CLI: aws s3api get-bucket-acl --bucket YOUR_BUCKET_NAME and aws s3api get-public-access-block --bucket YOUR_BUCKET_NAME. If the public access block is not enabled or the ACL grants access to "AllUsers" or "AuthenticatedUsers," the bucket is exposed. GrayhatWarfare.com indexes exposed S3 buckets - search for your company name.
How to fix it immediately
- Enable S3 Block Public Access: In the bucket settings, enable all four Block Public Access options. This overrides any ACL or policy that grants public access.
- Separate public and private content: Use separate buckets for publicly-accessible files (marketing assets) and private files (KYC documents, logs). Never mix them.
- Use presigned URLs: For files that users need to access (their own KYC documents, receipts), generate time-limited presigned URLs from your backend. The URL expires after 15 minutes; the bucket stays private.
- Enable access logging: Turn on S3 server access logging to track who accessed what and when. This provides forensic evidence if the bucket was accessed before you locked it down.
Cost of this exposure: A publicly accessible S3 bucket containing KYC images for a Nigerian fintech violates both NDPA requirements for personal data protection and CBN data handling directives. Beyond the ₦10 million+ regulatory fines, exposed government ID scans and BVN documents enable identity theft at scale - your customers become victims of fraud committed using their own verified identities.
6. Elasticsearch clusters accessible without authentication
Elasticsearch powers search, log aggregation, and analytics for many Nigerian fintech platforms. It is also one of the most frequently exposed services on the internet, because it does not include authentication in its default open-source distribution.
How it happens
Elasticsearch, in its free tier (formerly the Basic/Open Source license), ships without any built-in security features. No authentication. No encryption. No access control. The developer deploys it, configures the application to index transaction logs and user search queries, and never realizes that anyone who can reach port 9200 can read every indexed document. The cluster gets deployed on a server with a public IP, or the cloud security group allows inbound traffic on port 9200, and it is immediately discoverable.
How to check
From an external machine, open a browser and navigate to http://YOUR_PUBLIC_IP:9200/. If you see a JSON response with the cluster name and version, it is accessible. Navigate to http://YOUR_PUBLIC_IP:9200/_cat/indices to see all indices. Navigate to http://YOUR_PUBLIC_IP:9200/INDEX_NAME/_search to read the data. Search Shodan for your IP range filtered to port 9200.
How to fix it immediately
- Enable security features: Elasticsearch 8.x enables security by default. For older versions, set
xpack.security.enabled: trueinelasticsearch.ymland configure the built-in users withelasticsearch-setup-passwords. - Bind to localhost or private network: Set
network.host: 127.0.0.1or the private network interface inelasticsearch.yml. - Firewall the port: Block port 9200 and 9300 (cluster communication) from all public access at the OS and cloud security group level.
- Enable TLS: Configure TLS for both HTTP (client-to-node) and transport (node-to-node) communication.
Cost of this exposure: Elasticsearch often contains aggregated data from multiple sources - transaction logs, search queries, user activity, error logs with stack traces containing database credentials. A single exposed cluster can leak more operational intelligence than any other single system. Remediation after exfiltration typically costs ₦15-30 million when accounting for forensics, notification, and regulatory compliance.
The StackOverflow copy-paste pipeline
In four out of five cases where we find exposed databases during Nigerian fintech assessments, the root cause is the same: a configuration block copied from a StackOverflow answer or tutorial blog post that was written for development environments, pasted into a production configuration file, and never revisited. The fix is not technical sophistication - it is a deployment checklist that explicitly verifies database access controls before every production release. See our fintech security checklist for a production-ready template.
Systematic prevention
Fixing individual exposures is necessary but insufficient. The configuration mistake will recur unless you address the process that allowed it.
- Infrastructure as Code: Define all database configurations in Terraform, Pulumi, or CloudFormation templates with security settings baked in. Review templates in pull requests the same way you review application code.
- Automated scanning: Run monthly external scans against your IP ranges for open database ports (27017, 6379, 5432, 3306, 9200, 9300). Vulnerability assessments catch what manual checks miss.
- Security group audits: Quarterly review of all cloud security groups and firewall rules. Flag any rule that allows inbound traffic from 0.0.0.0/0 to a database port.
- Secrets management: Move all database credentials to a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler). Rotate credentials quarterly. Never store them in .env files or source code.
- Deployment checklists: Before every production deployment, verify: database authentication enabled, binding restricted, ports firewalled, TLS configured, credentials rotated.
We find exposed databases in the majority of first-time infrastructure assessments we run for Nigerian fintechs. A 30-minute conversation can determine your risk exposure.
Check Your Infrastructure SecurityRelated reading
Blog: .env Files in Production · Where to Store API Keys and Secrets · Securing PostgreSQL in Production · Cloud Security Checklist
Guides: Fintech Security Checklist · OWASP for Fintech · After a Breach
Services: Vulnerability Assessment · Secure Architecture Review · Digital Banking Security
Frequently asked questions
How do I know if my database is exposed to the internet?
The fastest way is to check from outside your network. Use Shodan (shodan.io) and search for your company's IP range or domain. If your database port (27017 for MongoDB, 6379 for Redis, 5432 for PostgreSQL) shows up in results, it is internet-accessible. You can also use nmap from an external machine to scan your IP for open database ports. If the port responds, it is exposed.
Is MongoDB really insecure by default?
Yes. MongoDB's default configuration prior to version 6.0 ships with authentication disabled and binds to all network interfaces. This means if you install MongoDB on a server with a public IP and do not explicitly enable authentication and restrict the bind address, anyone on the internet can connect to your database with no credentials. Thousands of MongoDB instances are discovered this way on Shodan every month.
What is the NDPA penalty for exposing customer data through a misconfigured database?
Under the Nigeria Data Protection Act (NDPA), the NDPC can impose fines of up to 2% of annual gross revenue or ₦10 million, whichever is greater, for failure to implement appropriate technical measures to protect personal data. An internet-exposed database with no authentication is a textbook failure of appropriate technical measures.
How quickly can an exposed database be found by attackers?
Internet-wide scanners like Shodan, Censys, and criminal botnets continuously scan all IPv4 addresses. A newly exposed database is typically indexed within 24 to 48 hours. Automated ransomware bots specifically target exposed MongoDB and Elasticsearch instances, often wiping the data and leaving a ransom note within hours of discovery.