I've checked what is sanitization of user inputs. And now I stuck with idea hot to automate tests for the sanitization of user inputs?

I'm new about this topic.

  • 2
    What have you checked? For instance, Google returned me this link as the first result: dev-tester.com/test-your-form-inputs-with-naughty-strings. Is this article enough? If no, then why?
    – dzieciou
    Jan 26, 2023 at 11:42
  • Questions to help clarify: what type of inputs are you working with? Profile Creation? Login? Ecommerce checkout, etc? What rules do your inputs have? What are the criteria for them?
    – Lee Jensen
    Jan 26, 2023 at 18:42

5 Answers 5


This is phrased a bit in "developer terminology." I highly encourage people in testing roles to learn more technical topics as this helps in communicating with your team.

Another way of saying "sanitization of user inputs" is: Do your user input fields behave correctly in positive ways, negative ways, or other ways? This gets into "validation" which is one way to ensure sanitization.

Here is where test case design utilizing Boundary Value Analysis and Equivalence Classes really helps. Of course, you also need to understand the requirements and rules your input fields have. We don't know the rules on the OPs question, so it's hard to be more specific.

For a brief example, let's talk about a login creation input where you have an input field for username and another for password. And let's have the following criteria:

  • Username = email address
  • Password = 8-12 characters in length, numbers, letters, minimum 1 uppercase alpha, minimum 1 symbol (!@#$%)

What do your high-level test cases look like (non-exhastive)?

  • Valid email address and valid password allow for login to be created.
  • Invalid email address (user@) causes an error (validate the error message)
  • Invalid password causes an error (validate the error message)
  • What happens if you try an email address already in use? (validate the error message)

There are so many options here for invalid email addresses and invalid passwords based on the example criteria. Lots have been written on Boundary Value Analysis and Equivalence Classes, so use those as search terms here in the SQA Stack Exchange or via Google.

Already with these test cases, you have 1 positive test case and numerous negative test cases. For other test cases:

  • Do your inputs follow security guidelines: see OWASP Top 10 rules.
  • Do your inputs follow encoding/decoding correctly

Sanitization can also look like:

  • Strip whitespace at the beginning and end of the input
  • Character escaping
  • Checking for empty strings or nulls

Where does automation come in?

  • You can create unit tests for most, if not all, the Boundary Value Analysis and Equivalence Classes test cases you came up with.
  • You can programmatically strip white space, escape characters, encoding/decoding, and even check for empty strings or nulls!
  • You can automate for the OWASP Top 10 rules.

In general, sanitization and validation are all about defense programming!

There's a ton I can write on this topic, but hopefully, this gets you started in the right direction!


Input Validation

Apply rules to the information that users are providing

As the name validation suggests, input validation (also referred to as sanitizing input) is about examining what data the user is supplying against a number of rules and then providing feedback to the user about issues when their input fails these rules. The term 'sanitized' puts emphasis that only data that meets the rules ('is sanitized') is accepted and stored.

The most common example of this is typically seen in email and password inputs, for example email must have an @, password must have at least x number of characters, etc.

Automation of sanitization is then the same as other testing, i.e.

  • Given input data
  • When a validation / sanitization rule is applied
  • When the input fails the rule, let the user know and prevent them from proceeding until fixed.
  • When the input passes the rule, let the user proceed

"Where to test" is an interesting aspect.

Testing through the browser is probably the first thing that comes to mind. It comes with two significant problems however (inherent in browser testing):

First, the route to get to the point where a validation can be long and complicated - not good for browser tests which are slow and flaky. Secondly, if you try to do all the validation in one UI test you are testing multiple conditions with one test and you lose the 'one assertion per test' approach.

Secondly, your specific validation tests may now be be dependent or interfered with by other tests. For this reason I recommend you consider having one happy and one sad path UI (browser) test (failing validation is a sad path test), then using unit tests to test all the variety of conditions. These could be either framework tests with the network stubbed out or backend unit tests if the validation is done there.


Input sanitization is a cybersecurity measure of checking, cleaning, and filtering data inputs from users, APIs, and web services of any unwanted characters and strings to prevent the injection of harmful codes into the system.

An application receives queries and requests from untrusted sources that might expose the system to malicious attacks. Input sanitization ensures that the entered data conforms to subsystem and security requirements, eliminating unnecessary characters that can pose potential harm.

Attackers have been using classic flaws for years with a pretty high success rate. Classic approaches such as SQL injection, XSS, RFI (remote file inclusion), or directory traversal are still the most common attacks.

Benefits of input sanitization:

  1. Providing a perimeter defense against common cyberattacks
  2. Preventing some forms of remote file inclusion and injection attacks (Code injection, SQLi, and XSS)
  3. Protecting the system from malicious code intrusions

For more details:

  1. Input Sanitization
  2. How to Prevent Web Attacks Using Input Sanitization

Automating tests for sanitization of user inputs involves testing the application's ability to correctly filter and modify user inputs to prevent security issues like XSS (Cross-Site Scripting), SQL Injection, etc. Here are the steps you can follow to automate such tests:

  1. Identify the various types of inputs that can be entered into the application - text inputs, drop-down lists, radio buttons, etc.

  2. For each input type, create a test case that tests the application's ability to sanitize user inputs.

  3. Input different types of malicious data into each input field, such as SQL injection code, XSS script, etc.

  4. Verify that the application properly sanitizes the input data and returns a safe result.

  5. Repeat this process for each input type, making sure to cover all the different ways malicious data can be entered.

  6. Finally, write automated tests to repeat these steps and verify that the application continues to properly sanitize user inputs.

Tools like Selenium and JUnit can be used to automate these tests. You can write code to input different types of malicious data into the application and verify that the application properly sanitizes the inputs and returns a safe result.

For more information on automated testing for sanitization of user inputs, you can refer to the OWASP (Open Web Application Security Project) guidelines on input validation and sanitization.



Both the upvoted answers are fantastic. Here's a TL;DR version:

  1. Create extensive sanitization rules tests as unit tests.
  2. Automate happy path tests for the app's desired login workflow behavior when a user inputs bad data into each of the fields and/or a combo of the fields.
  3. Download or create a file of all the many dangerous inputs and automate a fuzzing test against your login functionality. Example: a' or 1=1-- is a common one

Enjoy! This is a very fun one to automate.

  • Downvoter, please provide suggestions for improvement.
    – LazyDragon
    Jan 31, 2023 at 17:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.