Security Engineering / Database Security
Database Security
Your database holds the data attackers want. We audit who can reach it, who can read what, how it's encrypted, and how it's backed up across PostgreSQL, MySQL, MongoDB, SQL Server, and Supabase, then help you lock it down without breaking your app.
What Is Database Security?
Database security is the set of controls that protect a database from unauthorized access, data leaks, and data loss. It covers network exposure, authentication, user roles and privileges, row-level access rules, encryption, auditing, and backups. A database security audit checks each of these against best practice and benchmarks such as the CIS Benchmarks for your database engine.
This Is For You If...
Your app connects to the database with one all-powerful user
Your database is reachable from the internet, even if it has a password
You use Supabase or Firebase and aren't sure your access rules are right
You store personal, health, or payment data
You haven't tested restoring a backup recently
What We Audit
Network Exposure
Public endpoints, firewall rules and allow-lists, private networking, and exposed admin ports.
Authentication
Password strength and hashing method, certificate authentication, default and shared accounts, and connection rules such as pg_hba.conf in PostgreSQL.
Roles & Privileges
Least-privilege roles for the app, admins, analytics, and migrations, superuser use, and grants on tables, views, and functions.
Row-Level Security
Policies that keep each user or tenant to their own rows in PostgreSQL and Supabase, and security rules in Firebase. See Multi-Tenant Systems.
Encryption
TLS for connections, encryption at rest, column-level encryption for sensitive fields, and key management.
Auditing & Monitoring
Logging of logins, privilege changes, and sensitive queries, with alerts on unusual access.
Backups & Recovery
Backup encryption and access, point-in-time recovery, and a tested restore. See Replication & Backup.
Application Layer
SQL and NoSQL injection risks, connection strings and secrets in code, and unsafe ORM usage.
Databases We Audit
Database | Key Checks |
PostgreSQL | Roles, pg_hba.conf, row-level security, extensions, SSL, audit logging with pgAudit |
MySQL and MariaDB | User grants, remote root access, TLS, audit plugin |
MongoDB | Authentication enabled, role-based access, network binding, TLS |
Microsoft SQL Server | Logins and roles, Transparent Data Encryption, auditing |
Supabase | RLS policies on every table, service-role key exposure, storage bucket policies |
Firebase and Firestore | Security rules, test-mode rules left in place, API key restrictions |
Managed cloud databases (Amazon RDS, Cloud SQL, Azure SQL) | Public access, parameter settings, IAM authentication, snapshot sharing |
Common Mistakes to Avoid
Instinct | Why It Doesn't Help | Do This Instead |
Connecting the app as a superuser or owner | One SQL injection can expose or delete everything | Give the app a role with only the privileges it needs |
Putting the database on a public IP | It's exposed to constant brute-force attempts | Use private networking and allow-lists |
Enabling RLS on some tables, not all | One forgotten table can leak every user's data | Check every table and test as each role |
Using the Supabase service-role key in the frontend | It bypasses all row-level security | Keep service keys on the server only |
Never restoring a backup | You don't know whether recovery works | Test restores on a schedule |
What You Get
Risk-ranked findings for each database
A role and privilege map showing who can access what
Row-level security test results for each role and tenant
Ready-to-run SQL or configuration fixes
A backup and recovery check
A retest and a shareable summary
What We Need From You
What to Share | Why It Helps |
Read-only admin or audit access | Lets us review settings, roles, and policies |
The schema and a list of sensitive tables | Focuses the review on the data that matters |
Test accounts for each app role | Needed to test row-level access |
Backup and hosting details | Shows how recovery is set up |
How It Works
1. Scope and access
Databases agreed, read-only access granted
2. Configuration review
Network, authentication, encryption, and logging settings checked
3. Access testing
Queries run as each role to confirm what each one can reach
4. Report
Risk-ranked findings with SQL and configuration fixes
5. Fix
Changes tested against your app, then applied with your approval
6. Retest
Confirm the gaps are closed
How Database Security Supports Compliance
GDPR, HIPAA, and SOC 2 all expect access control, encryption, and audit logs around personal data. Our findings map to these requirements, so the same work counts toward your compliance evidence. See GDPR Compliance, HIPAA Compliance, and SOC 2 Readiness.
Why Codersarts
We design and scale databases as well as secure them, so changes such as new roles, RLS policies, or private networking are tested against your application before they go live. See Database Engineering.
Turnaround Time
A typical audit of one production database takes 3 to 5 working days, including the report. Approved fixes are usually applied within a week after that.
FAQ
What is row-level security?
Row-level security (RLS) is a database feature that limits which rows each user can read or change, based on rules you define. In PostgreSQL and Supabase it is how multi-tenant apps keep each customer's data separate.
Is Supabase secure by default?
Supabase gives you strong tools, but security depends on your RLS policies. Tables without RLS, or with policies that are too broad, can expose data through the public API.
Will the audit change or slow down our database?
No. The audit uses read-only access. Changes are made only with your approval and are tested first.
Do you audit NoSQL databases?
Yes, including MongoDB, Firebase and Firestore, DynamoDB, and Redis.
Our AI-built app is leaking data. Is this the right page?
If your app was built with Lovable, Bolt, or a similar tool, start with Data Exposure in AI-Built Apps.
Is our project kept confidential?
Yes. Your data, code, and results stay confidential, and an NDA is available on request.
Related Services
Who Can Read Your Customer Data Right Now?
Get a clear answer and the fixes to tighten it.