I&#x27;ve been doing penetration testing of web applications professionally for about 5 years now. The incidence of SQLi has definitely decreased over the years but I would estimate that we still identify it on approximately 1 of every 5 web apps that we test for our clients. Usually, the more obvious SQLi has been found and patched already years ago. An example of obvious SQLi is &#x27;error based SQLi&#x27; where the application returns verbose error messages such as:<p><pre><code>  &quot;You have an error in your SQL syntax; check the manual
  that corresponds to your MySQL server version for the
  right syntax to use near &#x27;\&#x27;&#x27; at line 1&quot;
</code></pre>
As soon as we see an error message like this, we know we can dump the entire database in a matter of minutes.<p>These days, we usually have to work a bit harder to find the more difficult to identify and exploit SQLi (e.g. boolean-based blind and time based) but the end result is the same once we do. SQLMap is a standard tool in a any good web app penetration tester&#x27;s toolkit. It&#x27;s not always going to work but when it does it automates away a lot of the grunt work. I applaud the SQLMap developers who seem to know SQL inside out and actively acknowledge feedback from the community.<p>For any devs, this is decent guide for preventing SQLi:<p><a href="https:&#x2F;&#x2F;www.owasp.org&#x2F;index.php&#x2F;SQL_Injection_Prevention_Cheat_Sheet" rel="nofollow">https:&#x2F;&#x2F;www.owasp.org&#x2F;index.php&#x2F;SQL_Injection_Prevention_Che...</a>