Our development team relies heavily on Hibernate for database operations. Are we completely immune to vulnerabilities by using an ORM, or are there specific edge cases we must watch out for?
3 answers
You are definitely not completely immune. While Hibernate safely automates parameterization when using its built-in criteria APIs or standard data mapping features, vulnerabilities arise if you write custom Hibernate Query Language or Java Persistence Query Language strings via concatenation. If user input is directly stitched into an HQL string instead of using bound positional or named parameters, an attacker can manipulate the logic just like standard SQL, leading to what is known as HQL injection.
Have you integrated any static application security testing tools into your CI/CD pipeline to scan your repository for improper HQL string concatenation or raw native query configurations?
If you ever switch to native SQL queries within Hibernate using createNativeQuery, you completely lose ORM protections unless you explicitly bind your parameters manually.
Native queries are a major blind spot. Developers think the framework protects them globally, but native execution completely strips away those built-in security abstractions.
We don't have an automated SAST tool integrated into our deployment pipeline yet. We still rely on manual code reviews, which is why I want to make sure our code patterns are sound.