Client Programming Security Guidelines provides data streaming from remote storage, parallel loading of tables or table chunks, progress state tracking, resume and reset capability, and the option of concurrent loading while the dump is still taking place. MySQL Shell’s parallel table import utility can be used in combination with the dump loading utility to modify data before uploading it to the target MySQL instance. For details of the utilities, see MySQL Shell Utilities. Client applications that access MySQL should use the following guidelines to avoid interpreting external data incorrectly or exposing sensitive information. Applications that access MySQL should not trust any data entered by users, who can try to trick your code by entering special or escaped character sequences in Web forms, URLs, or whatever application you have built. Be sure that your application remains secure if a user tries to perform SQL injection by entering something like  ; DROP DATABASE mysql;  into a form. This is an extreme example, but large security leaks and data loss might occur as a result of hackers using similar techniques, if you do not prepare for them. A common mistake is to protect only string data values. Remember to check numeric data as well. If an application generates a query such as  SELECT * FROM table WHERE ID=234  when a user enters the value  234 , the user can enter the value  234 OR 1=1  to cause the application to generate the query SELECT * FROM table WHERE ID=234 OR 1=1 . As a result, the server retrieves every row in the table. This exposes every row and causes excessive server load. The simplest way to protect from this type of attack is to use single quotation marks around the numeric constants:  SELECT * FROM table WHERE ID=’234’ . If the user enters extra information, it all becomes part of the string. In a numeric context, MySQL automatically converts this string to a number and strips any trailing nonnumeric characters from it. Sometimes people think that if a database contains only publicly available data, it need not be protected. This is incorrect. Even if it is permissible to display any row in the database, you should still protect against denial of service attacks (for example, those that are based on the technique in the preceding paragraph that causes the server to waste resources). Otherwise, your server becomes unresponsive to legitimate users. Checklist: •Enable strict SQL mode to tell the server to be more restrictive of what data values it accepts. See Section 5.1.11, “Server SQL Modes” . •Try to enter single and double quotation marks ( ’  and  " ) in all of your Web forms. If you get any kind of MySQL error, investigate the problem right away. •Try to modify dynamic URLs by adding  %22  ( " ),  %23  ( # ), and  %27  ( ’ ) to them. •Try to modify data types in dynamic URLs from numeric to character types using the characters shown in the previous examples. Your application should be safe against these and similar attacks. •Handle External Data Properly •Handle MySQL Error Messages Properly 6.1.7 Client Programming Security Guidelines Handle External Data Properly 1182