Hi @HVerma797599 (Community Member)​ ,

The best approach towards fixing CWE-89 SQL injection flaws for any language (including Android) is to not build your SQL queries using simple string concatenation where your inputs originate from dynamic untrusted sources. You want to instead build and run any queries containing dynamic inputs by declaring parameterized prepared statements where you then bind the dynamic marked values to expected data types (strings, ints, etc.). Doing this will signal to your database helper library that it must not improperly interpret any dynamic values passed into your query as arbitrary SQL code to run as part of the SQL query string you build. Instead, it will be instructed to treat the values strictly as non-executable data as the data type you've specified.

Though it can be viewed as optional, It is also a good idea to pair any prepared statement implementations alongside any custom known good input validation checks you can declare. This helps ensure the dynamic inputs coming into your query can only contain values you expect users to provide before the prepared statement even is invoked. It can serve as a good defense in depth strategy in case there are any flaws in how you defined your prepared statements.

Using the prepared statement (with optional additional input validation) approach should cover any desired database operations you wish to perform, including both of the example DB methods you've mentioned. Setting up and declaring the query properly using parameterized prepared statements is the essential step here, at which point it should then be safe to invoke your desired database calls by referencing the prepared statement.

If you haven't already, I would greatly suggest taking a look at the recommendations and examples Veracode has provided on how to fix CWE-89 flaws in each of these resources. These go into many different kinds of cases and examples where SQL injection can occur and how to best resolve each case. Links to other supporting references on the topic are also provided for further consideration (the OWASP "SQL Injection Prevention Cheat Sheet" guide is also highly recommended)

https://community.veracode.com/s/article/How-to-fix-CWE-89-SQL-Injection-flaws

https://community.veracode.com/s/article/sql-injection-mitigation-page2

Note how in some of these cases, prepared statements as I've described above will not work as a viable solution, however you still have the ability to fallback and go with other mitigation approaches such as strong input validation schemes or other controls available in your database environment. These do however require more care and consideration from your team in order to properly ensure a level of secure mitigation similar to what prepared statements provide, so be mindful of that.

Also note that while Java is the primary language used to illustrate code examples in the above links, the cases should be easy to map over to other languages/frameworks and the DB helper libraries they provide. Android should already have access to the same `PreparedStatement` command that is usually suggested in Java SQL Injection mitigation source code examples. If you are making use of SQLite as your backend database with the Android database SQLite helper class, then you could also accomplish the same prepared statement strategy using the `compileStatement` command.

Should you still have any questions on this particular flaw category as it relates to your specific use case, I highly encourage setting up a consultation call and using that to discuss your concerns further. You can check out this knowledge article ( https://community.veracode.com/s/article/How-to-schedule-a-consultation-call) on how to schedule a consultation call with our team.

Thank you,

Andrew Bell