4 ms·
I can see how something like this is a nice addition to your tool set, but you really should have good automated tests at build time anyway to catch SQL errors.
by sverhagen 7y ago
I can see how something like this is a nice addition to your tool set, but you really should have good automated tests at build time anyway to catch SQL errors.
- rgharris 7y agoI agree, end-to-end tests have been really valuable for catching SQL issues in my experience. > Identify unsafe queries that could potentially lead to SQL injections This feature seems like a perfect use case for static analysis and would be a great tool in addition to automated tests.
- sverhagen 7y agoAnd static analysis is not limited to build time so it can provide value even earlier.
- pletnes 7y agoOr later, if your program grows from a small hack to an important application.
- namibj 7y agoJust don't use string mangling to combine parameters and queries. The most is switch/case in a loop or something like it doing state machine execution to combine fixed strings. And that only because one does not accidentally build something general enough to allow for SQL injection with such harsh restrictions.
- cgh 7y agoThis can even be done locally if your tests start and populate an in-memory database like Derby. Before anyone says it, I’m not talking about ordinary unit tests, but they can be part of the test suite.
- taeric 7y agoWith embedded databases, I'm fine of not just checking syntax of queries, but the logic that relies on the store. Not a panacea, but very nice regardless.