Keep application databases off the public internet
A public website can use a private database. Review connection routes, database rules and permissions, then verify both allowed and rejected access.
Rootscratch ·
A public website can use a private database. Limit incoming database connections to approved application hosts and a separately authorized administrative route. OWASP recommends isolating backend databases and restricting network access to specific hosts.[1]
Map who needs a connection
Ask the developer to list the application servers, background jobs and maintenance tools that need database access. Give each route an owner and a purpose. Treat a temporary troubleshooting connection as a change to review, with a removal step, rather than an exception nobody remembers afterward.
AWS documents an Amazon RDS setup where public-facing web servers connect to a database in a private subnet. Its public-access setting, subnet routing and security-group rules affect external reachability.[2] Review those controls together; a reassuring label in the hosting console is not the whole connection policy.
For a database on the same host as the application, a local socket or loopback-only connection may be appropriate. OWASP lists these alongside restricted network access.[1] Choose the design for the actual deployment, not a configuration copied from a different hosting model.
Check the database rules too
PostgreSQL separates the interfaces it listens on from client authentication rules. Its listen_addresses setting controls which interfaces accept connection attempts; pg_hba.conf selects authentication by connection type, client address, database and user.[3][4]
Ask the reviewer to explain both. PostgreSQL uses the first matching authentication record and does not try later records after authentication fails.[4] A narrowly written rule below a broader match may never govern the connection you intended to restrict. Inspect the effective order before changing it.
A private network also needs protected traffic. PostgreSQL's client documentation distinguishes encryption from checking the server's identity: verify-full verifies the certificate chain and the requested host name.[5] Have the developer confirm the equivalent safeguards for the driver and database your application uses.
Verify allowed and rejected routes
Within a written test scope, check an ordinary application task from the permitted host. Then check that an unapproved network location cannot reach the database's network port. Record where each test originated and whether the network blocked the attempt or the database only refused authentication. Do not scan systems you do not own or have permission to test.[6]
Keep those checks separate from database permissions. OWASP recommends accounts with only the privileges their application needs, rather than built-in administrative accounts.[1] Restricting the connection route does not limit what an overprivileged application can do after it connects.
Include the expected connection checks in future hosting and deployment reviews. If a maintenance route needs to change, document the reason and verify the boundary again before calling the change complete.
Rootscratch's Cyber Security Services include scoped application and configuration review, remediation guidance and retesting.[6] Start with the application's purpose and the database-access concern. Agree on assets and permitted methods before testing; share credentials only through the secure process arranged afterward.[6]
Sources
[1] https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html — OWASP: Database Security Cheat Sheet [2] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html — Amazon RDS: database instances and private network access [3] https://www.postgresql.org/docs/current/runtime-config-connection.html — PostgreSQL: connection interfaces and authentication settings [4] https://www.postgresql.org/docs/current/auth-pg-hba-conf.html — PostgreSQL: client authentication rules in pg_hba.conf [5] https://www.postgresql.org/docs/current/libpq-ssl.html — PostgreSQL: SSL support and server identity verification [6] https://rootscratch.com/services/cyber-security — Rootscratch: Cyber Security Services