Following are a few (and brief) guidelines to make a webapp pentester’s life measurably harder. Server-side Input Validation- Input validation that is enforced on the server side runs its own validation checks against the user input to determine whether or not it is “safe”, and contains disallowed characters. This type of validation is nearly impossible to bypass. On the flip side, client side input validation can easily be bypassed by simply disabling JavaScript in the client’s browser or manually issuing the HTTP request by using an intercepting proxy (BurpSuite, OWASP ZAP, etc). ASP.NET has native functionality to perform request validation, and other popular programming languages (PHP, JSP, and JavaScript) are capable of validating requests. Input Sanitization - During an assessment, once the initial mapping phase of a web application is complete, I like to go through any and all dynamic content and parameters to investigate how said parameters are handling input. For example, I may issue a request with HTML metacharacters (< > “ and /) and check the application’s response to see if they are echoed back verbatim.  In this specific case if any of the characters come back sanitized as HTML entities (&lt; &;gt &quot; and %2f respectively) we can see that those types of characters are properly sanitized before returning back into the client’s browser (if that specific parameter takes and returns input). Essentially, if it only displays the code on the page (HTML entities) instead of rendering (HTML Metacharacters) this would prevent any type of HTML Injection, Cross-Site Scripting, etc. Custom or Vague error message - Error messages are very useful to a webapp tester, as the default error messages usually divulge quite a bit of information about what and how (we) caused the error.  These errors can contain very valuable information such as SQL queries, information about the SQL queries being executed in the back-end, SOAP errors, and function errors(depending on the application’s language). Configuring the web application to use generic or customized error messages only makes it harder and much more time consuming to determine if a vulnerability is present. Parameterized Queries/Prepared Statements - When we find that user input is being directly inserted into a SQL query that is being executed on the back end, it is usually an exciting find. A full compromise of the backend database could be just a matter of time once discovered. By implementing parameterized queries or prepared statements, there is no need to escape parameters as data is not treated the same in the prepared statement, resulting in non-injectable inputs. These are the most common defense mechanisms that we encounter on a daily basis, and can cause quite the headache at times.