Security Best Pratices for Java Developer

Security is playing vital role in your  project . While devloping our application following areas we have to verify .

Area	What to look for
SQL injection	A SQL injection attack occurs when untrusted input can modify the semantics of a SQL query in unexpected ways. As you review the code, make sure that the SQL queries are parameterized and that any input used in a SQL query is validated.
Cross-site scripting	Cross-site scripting occurs when an attacker manages to inject script code into an application so that script code is echoed back and executed in the security context of the application. This can allow an attacker to steal user information, including forms data and cookies. This vulnerability can be present whenever a Web application echoes unfiltered user input back to Web content.
Data access	Look for improper storage of database connection strings and proper use of authentication to the database.
Input/data validation	Look for client-side validation that is not backed by server-side validation, poor validation techniques, and reliance on file names or other insecure mechanisms to make security decisions.
Authentication	Look for weak passwords, clear-text credentials, overly long sessions, and passwords or secrets being stored in session data
Authorization	Look for failure to limit database access, inadequate separation of privileges, and mechanisms to work around authorization checks.
Sensitive data	Look for mismanagement of sensitive data by disclosing secrets in error messages, code, memory, files, or the network.
Hard-coded secrets	Look for hard-coded secrets in code by looking for variable names such as "key", "password", "pwd", "secret", "hash", and "salt".
Poor error handling	Look for functions with missing error handlers or empty catch blocks.
Too verbose error handling	Look for functions which do data integrity validation before checking data access authorization. Such error handling may reveal too much information about what is in the database to an unauthorized user.
Undocumented public interfaces	Most undocumented interfaces should not be in the application, and they are almost never given the same level of design and test scrutiny as the rest of the code. If an operation is exposed as a public interface, check that it actually required.
Threading problems	Check for race conditions and deadlocks, especially in static methods and constructors.
Unreleased resources	Look for allocation of resources for a request that are not released when the request is serviced.
Assigning resources before authentication	Look for allocation of resources prior to authentication.