Hey guys!

On February 6th, I participated in the Round Table #212 on the Coding Night channel, in an extensive and deeply practical conversation about security when using databases, having as main reference the materials of the OWASP. The live's proposal was not to present new or sophisticated solutions, but to revisit fundamentals that continue to be ignored, even after decades of consolidated recommendations.

Throughout the discussion, it became clear that most security incidents involving databases are not associated with complex attacks or advanced techniques, but rather with neglect of basic practices, widely documented and known by the technical community.

Stream link:

OWASP as a conceptual and practical basis

One of the first points covered was the contextualization of OWASP. More than a list of vulnerabilities, OWASP has established itself as a global reference in good security practices, based on continuous observation of the most recurrent attacks in the real world.

The known OWASP Top 10 it emerged precisely from the statistical analysis of the most frequent attacks on applications. As the community matured, this work evolved into more specific materials, such as:

  • OWASP Top 10 for APIs

  • OWASP Top 10 for CI/CD

  • OWASP Top 10 for Containers

  • OWASP Database Security Cheat Sheet

These materials function as practical checklists, and not as academic theory. The live focused precisely on discussing how these recommendations apply to the daily lives of those who work with databases, development and infrastructure.

Basic security is still the biggest bottleneck

A point reinforced several times was that most of the vulnerabilities exploited today are extremely well known. SQL Injection, credential exposure, banks accessible directly over the internet, excessive permissions and lack of encryption continue to appear in productive environments.

This is not a question of profound technical lack of knowledge, but of lack of discipline, deadline pressure and accumulation of technical debt that is never addressed.

Security is often sacrificed when deadlines are tight. The problem arises when this decision is not recorded, prioritized or revisited later. Technical security debt is assumed but never paid.

Database backend protection and network isolation

An important part of the conversation was dedicated to database backend protection, starting with isolation at the network level. The first line of defense for any bank should be to ensure that it is not unnecessarily accessible.

Practices such as:

  • Restrict connections to only specific hosts or IPs

  • Avoid direct exposure of the bank to the internet

  • Use firewalls, network rules and, when possible, DMZs

  • Ensure that only application servers can connect

Even if a credential is compromised, the attacker should not be able to establish a connection if it is outside the expected context. This type of control drastically reduces the attack surface.

Authentication and the problem of forgotten credentials

Another central point was the way authentication is implemented. Banks that use authentication based only on username and password create a recurring problem: credentials that remain valid indefinitely.

It was discussed how integrated authentication (e.g. Active Directory or Single Sign-On) brings clear benefits:

  • There is no password traveling over the network

  • Deactivating a user automatically invalidates all access

  • Dramatically reduces the risk of orphaned accounts

Real cases were mentioned where former employees maintained indirect access to the database simply because the credential was never removed.

Principle of least privilege in practice

The principle of least privilege was treated not as an abstract concept, but as a daily practice. Granting broad permissions “for convenience” is one of the most common and dangerous mistakes.

It was highlighted that:

  • Most applications do not need administrative permissions

  • Poorly controlled read access also poses a risk

  • Permissions should be granted in the smallest scope possible

Additionally, permissions need to be reviewed periodically, and not just during one-off audits. Environments without regular reviews tend to accumulate unnecessary access over the years.

Secure Credential Storage

Much of the live addressed the inappropriate storage of credentials in applications. Real-world examples have shown how passwords exposed in source code or configuration files are exploited in a matter of seconds.

Best practices discussed included:

  • Never version credentials

  • Use dedicated secret vaults

  • Restrict access to the vault to only those who really need it

  • Prefer environment variables only as an intermediate alternative

It was emphasized that password vaults not only protect credentials but also prevent accidental exposure during screen sharing, recordings or demonstrations.

Encryption at rest and in transit

The discussion on encryption made it clear that protecting stored data alone is not enough. Data also needs to be protected during traffic between application and bank.

The use of:

  • TLS for bank connections

  • Valid certificates and secure protocol versions

  • Avoid accepting insecure connections even with redirection

The analogy used was simple: there is no point in protecting the safe if the money is transported without an escort.

Conscious management of technical debt in security

One of the most mature points of the conversation was the discussion about security technical debt. It is not always possible to implement everything correctly from the beginning, especially in startups or projects with aggressive deadlines.

The problem is not assuming the debt, but not recognize or register it. Known vulnerabilities need to be documented, prioritized and with a defined correction plan. Security cannot depend solely on people's memories.

Use of tools and automation as support

The live also showed how automated tools can help identify basic vulnerabilities before investing in more advanced tests. Static analysis tools (SAST), dynamic analysis tools (DAST), and API scanners help eliminate the “bad basics.”

These tools do not replace manual testing or specialized professionals, but they drastically reduce the number of trivial problems that make it to a formal audit.

Security as a collective responsibility

A point reinforced throughout the roundtable was that security is not the sole responsibility of DBAs, developers or infrastructure. It arises from interaction between all these areas.

Development decisions impact the bank. Infrastructure configurations impact the application. Communication failures between teams create gaps that would not exist if the problem were addressed jointly.

Final considerations

Round Table #212 reinforced something essential: security fails, most of the time, due to poorly done basics. It is not a lack of knowledge, nor tools, but of discipline, process and maturity.

As long as fundamental practices continue to be treated as optional, incidents will continue to happen. Security does not require complex solutions to begin with, it requires commitment to doing what is already widely known correctly.

This live aimed precisely to bring this reality to light, in a direct, technical way and in line with what really happens in the market.