Security Breach Prevention | Avoid Direct Access to Databases
Every single developer will tell you: frameworks exist to save time by avoiding you to reinvent the wheel again with something that will generally do worse than a specialized and generic layer. Sometime it’s true, but that’s another story…
When dealing with database, frameworks are also ultimately useful to mitigate the risk of creating security breaches in your own code, by making harder for a hacker to access your precious business data. That’s especially true if these frameworks are robust, mature and community-supported, like Hibernate or Spring are. Here, it’s not about time or velocity, it’s about million bucks an attack could cause for your business.
The programming good practice I’d like to discuss today from a benchmarking standpoint is about avoiding access to database tables directly from your components. It may sound obvious for developers and software architects, quite a shame to bypass the data access layer to fetch your result rows…
Paradoxically, the statistics we get from CAST Appmarq point out a controverted way of coding.
ISVs comply 4 times on 5 possible cases
Based on a sample consisting of 568 thousand opportunities found into hundreds of applications implemented with various technologies (JEE, .Net, C/C++, Visual Basic, etc.), 118 thousand violations were detected, giving a global compliance score of 79.09%. A pretty weak score if we consider other Security-related rules, which have generally a compliance score above 95%. In average, 253 defects of this kind can be found in an application.
Zooming to industries’ statistics is also revealing. Developers from the Software ISV industry comply with this rule 4 times on 5 possible cases (80.75%), while those from Insurance and Energy respectively get a compliance score of 67.86% and 66.08%.
Having a framework to manage data accesses in a secure way is a good thing… Using it is better.