If we want to say that our Database is secured then we must confirm first that our Data is validate.There are various methods of validating the Data:1. Accept only known valid Data.2. Reject known Bad Data.3. Sanitize Bad data. We cannot emphasize strongly enough that "Accept Only Known Valid Data" is the best strategy. We do, however, recognize that this isn't always feasible for political, financial or technical reasons, and so we describe the other strategies as well.All three methods must check: * Data Type * Syntax * Length Data type checking is extremely important. The application should check to ensure a string is being submitted and not an object, for instance.Accept Only Known Valid DataAs we mentioned, this is the preferred way to validate data. Applications should accept only input that is known to be safe and expected. As an example, let's assume a password reset system takes in usernames as input. Valid usernames would be defined as ASCII A-Z and 0-9. The application should check that the input is of type string, is comprised of A-Z and 0-9 (performing canonicalization checks as appropriate) and is of a valid length.Reject Known Bad DataThe rejecting bad data strategy relies on the application knowing about specific malicious payloads. While it is true that this strategy can limit exposure, it is very difficult for any application to maintain an up-to-date database of web application attack signatures.Sanitize All DataAttempting to make bad data harmless is certainly an effective second line of defense, especially when dealing with rejecting bad input. However, as described in the canonicalization section of this document, the task is extremely hard and should not be relied upon as a primary defense technique.