Hey guys!

On June 11th, I participated in the Round Table #222 on the channel Coding Night, in its second edition, with a total focus on security when using databases. The proposal of the live was to continue the previous edition and deepen critical points of the material from the OWASP, especially those that continue to be neglected even in mature corporate environments.

The conversation was conducted in an open, practical way and without the concern of “beautifying” the topic. The objective was to discuss what really happens on a daily basis, the most common mistakes and why security problems keep recurring, even when the recommendations are widely known.

Stream link:

OWASP Database Security Cheat Sheet as a common thread

We use as a basis the OWASP Database Security Cheat Sheet, which brings together recommendations organized from A to Z on database security. An important point highlighted at the beginning was that this material should not be seen as a theoretical list, but as a practical checklist.

Most serious security incidents do not occur due to sophisticated failures, but due to failure to implement basic controls, widely documented for years. SQL Injection, for example, continues to be explored not because it is new, but because it continues to be possible.

Authentication, identity and the problem of forgotten accounts

A significant part of the live was dedicated to authentication and identity management. We discuss how the use of integrated authentication (Active Directory, federated authentication or managed identities in the cloud) drastically reduces operational risks.

The recurring problem is the use of:

  • Local users in the database

  • Application accounts with excessive permissions

  • Credentials that remain active after employees leave

I explained that “forgotten” accounts are one of the biggest gateways to incidents. Often, the user does not even need to be external: someone who left the company, changed areas or returned as a third party can still have privileged access if this control is not carried out correctly.

Principle of least privilege applied realistically

Another central point of the discussion was the principle of least privilege, not just as a concept, but as an effective practice.

We talk about:

  • Avoid granting access at the database level when necessary at the table level

  • Prevent write permissions when use is read-only

  • The real risk of a simple poorly controlled read access generating unavailability (including denial of service attacks due to excessive reading)

It was reinforced that security is not just preventing writing or deleting data, but also ensure availability.

Application security: credentials, configuration and classic errors

The live event brought several real examples involving applications that store credentials in inappropriate locations, such as versioned configuration files in Git repositories. Cases where passwords have been publicly exposed and exploited within seconds show that this risk is not hypothetical.

We discuss practices such as:

  • Use of a secret vault or, at a minimum, environment variables

  • Never version credentials, even in private repositories

  • Take extreme care in live demonstrations, recordings and prints

We also commented on how platforms like GitHub have evolved to automatically detect secret leaks, but this does not replace good practices.

Database and operating system hardening

Another strong point of the live was the discussion about hardening, both the database and the underlying operating system. Shielding just the DBMS does not solve the problem if the OS is exposed.

Points such as:

  • Disabling dangerous features when not used (e.g. xp_cmdshell, CLR, SQL Browser)

  • Avoid using standard or widely known users

  • Clear separation between system and database administrative accounts

The central idea was to reduce the attack surface and make any attempt to elevate privilege more difficult.

Backup as a pillar of security, not just recovery

The backup strategy was treated as a security element, and not just business continuity. Real cases were cited where companies had to pay ransoms simply because they did not have valid, external backups.

We talk about:

  • Regular and tested backup

  • Backup encryption

  • External storage and, preferably, in the cloud

  • Clear definition of RPO and RTO aligned with the business

It was reinforced that the backup strategy should not be defined only by IT, but together with the business area, considering the financial and operational impact.

SQL Injection remains a current problem

Even after decades, SQL Injection still appears frequently in serious incidents. The discussion made it clear that the problem is not just in the language or the bank, but in the how applications are developed.

We highlight:

  • Mandatory use of parameters

  • Risks of poorly implemented dynamic SQL

  • False sense of security when using ORMs incorrectly

  • The need for input validation, regardless of the technology used

We also commented that databases cannot, by themselves, differentiate a legitimate query from a malicious query if the application delivers invalid SQL.

Granularity of access and isolation of environments

Another recurring theme was the proper separation between development, test and production environments. Sharing users and credentials across environments dramatically increases the risk of human error.

We also talk about:

  • Row-Level Security

  • Column-Level Security

  • Using views and procedures as additional layers of control

These mechanisms allow you to reduce exposure of sensitive data even when access is legitimate.

Final considerations

Round Table #222 reinforced something that I consider fundamental: Security does not fail due to lack of information, but due to lack of discipline. Most of the problems discussed involve basic practices that continue to be ignored due to haste, lack of process or overconfidence.

Database security is not the sole responsibility of DBAs, developers, or infrastructure. It is a joint, ongoing effort that needs to be treated as an essential part of the architecture, not as an optional complement.

This edition made it clear that, as long as good practices are not treated as standard, we will continue to see the same incidents repeat themselves, just with different names and technologies.