This article contains 97 JSON-based test cases designed to evaluate the functionality, reliability, validation controls, and security posture of an authentication endpoint.
The test suite covers a wide range of scenarios, including valid login requests, missing or malformed data, unexpected data types, special characters, Unicode handling, injection attacks, oversized payloads, encoding variations, and parser edge cases.
The objective of these tests is to verify that the authentication service correctly processes legitimate requests while securely rejecting invalid, malformed, or potentially malicious input. These test cases help identify weaknesses related to input validation, request parsing, authentication logic, data type handling, encoding support, and common security vulnerabilities such as SQL Injection, XSS, JSON Injection, and input truncation attacks.
Test 1: Basic Credentials
{"login": "admin", "password": "admin"}This test represents a standard authentication request using simple username and password values. It serves as the baseline test case to verify whether the authentication endpoint can successfully process valid credentials and return the appropriate login response.
Test 2: Empty Credentials
{"login": "", "password": ""}This test checks how the authentication system handles empty credential fields. It verifies whether input validation mechanisms correctly reject requests where both the username and password are supplied but contain no actual data.
Test 3: Null Values
{"login": null, "password": null}This test evaluates how the API processes explicitly null values instead of strings. It helps identify whether the application properly validates mandatory fields and prevents null values from being treated as legitimate authentication credentials.
Test 4: Credentials as Numbers
{"login": 123, "password": 456}This test submits numeric values instead of strings for both login and password fields. It verifies that the authentication endpoint enforces strict data type validation and does not automatically convert numbers into credential strings.
Test 5: Credentials as Booleans
{"login": true, "password": false}This test sends Boolean values rather than traditional text-based credentials. It helps determine whether the API validates field types correctly and rejects unexpected primitive data types during authentication processing.
Test 6: Credentials as Arrays
{"login": ["admin"], "password": ["password"]}This test uses arrays as credential values instead of simple strings. It evaluates the application’s ability to detect and reject complex JSON structures that do not match the expected authentication schema.
Test 7: Credentials as Objects
{"login": {"username": "admin"}, "password": {"password": "password"}}This test provides nested JSON objects in place of standard string credentials. It examines how securely the authentication service handles deserialization and whether object-based inputs could bypass validation logic.
Test 8: Special Characters in Credentials
{"login": "@dm!n", "password": "p@ssw0rd#"}This test verifies support for credentials containing special characters. Since modern passwords often include symbols to improve strength, the endpoint should correctly process these characters without causing parsing or validation issues.
Test 9: SQL Injection Attempt
{"login": "admin' --", "password": "password"}This test simulates a classic SQL injection payload in the login field. It checks whether authentication queries are properly parameterized and ensures that user input cannot manipulate backend database queries.
Test 10: HTML Tags in Credentials
{"login": "<h1>admin</h1>", "password": "ololo-HTML-XSS"}This test introduces HTML content into the login field. It helps identify whether the application treats HTML tags as ordinary text and prevents them from being rendered or executed in downstream systems such as logs, dashboards, or web pages.
Test 11: Unicode Encoded Credentials
{"login": "\u0061\u0064\u006D\u0069\u006E", "password": "\u0070\u0061\u0073\u0073\u0077\u006F\u0072\u0064"}This test supplies credentials using Unicode escape sequences instead of visible characters. It verifies that the JSON parser correctly decodes Unicode values and processes them consistently with their plain-text equivalents.
Test 12: Escape Characters in Credentials
{"login": "ad\\nmin", "password": "pa\\ssword"}This test evaluates how the application handles escape characters embedded within credential strings. It helps identify issues related to string parsing, sanitization, and backend processing of escaped data.
Test 13: Whitespace-Only Credentials
{"login": " ", "password": " "}This test submits credentials consisting entirely of whitespace characters. It verifies whether validation logic trims or rejects meaningless input before authentication attempts are made.
Test 14: Overlong Values
{"login": "a"*10000, "password": "b"*10000}This test uses extremely large credential values to evaluate system stability, resource management, and maximum input-length restrictions. It is commonly used to identify performance issues and denial-of-service weaknesses.
Test 15: Malformed JSON (Missing Brace)
{"login": "admin", "password": "admin"This test intentionally breaks JSON syntax by omitting the closing brace. It ensures that the API’s JSON parser detects malformed requests and returns an appropriate error rather than attempting authentication.
Test 16: Malformed JSON (Extra Comma)
{"login": "admin", "password": "admin",}This test includes an additional trailing comma that violates standard JSON syntax. It verifies whether the parser strictly follows JSON specifications and rejects incorrectly formatted payloads.
Test 17: Missing Login Key
{"password": "admin"}This test omits the login field entirely and provides only a password value. It checks whether the authentication endpoint properly enforces the presence of all required fields and rejects requests that do not conform to the expected authentication schema.
Test 18: Missing Password Key
{"login": "admin"}This test includes a login value but excludes the password field. It verifies that authentication cannot proceed when mandatory credentials are incomplete and that the API returns appropriate validation feedback.
Test 19: Swapped Key Values
{"admin": "login", "password": "password"}This test replaces the expected login key with an unexpected key name. It evaluates whether the system validates request structure correctly and ensures that authentication fields must use the exact expected property names.
Test 20: Extra Keys
{"login": "admin", "password": "admin", "extra": "extra"}This test adds an unnecessary field to an otherwise valid authentication request. It determines whether the API ignores unknown fields, logs them, or rejects requests that contain unexpected attributes.
Test 21: Missing Colon
{"login" "admin", "password": "password"}This payload intentionally violates JSON syntax by removing the colon between the key and value pair. It verifies that the JSON parser correctly detects malformed requests and prevents them from reaching application logic.
Test 22: Invalid Boolean Values
{"login": yes, "password": no}This test uses unquoted words that resemble Boolean values but are not valid JSON. It examines whether the parser strictly follows JSON standards and rejects unsupported literals during request processing.
Test 23: Empty Keys and Values
{"": "", "": ""}This test uses empty strings as both key names and values. It helps determine whether the authentication endpoint properly enforces required field names and handles invalid schema definitions safely.
Test 24: Nested Objects
{"login": {"innerLogin": "admin"}, "password": {"innerPassword": "password"}}This test sends deeply nested objects instead of simple string credentials. It evaluates how the application handles unexpected object structures and whether nested values could cause validation bypasses.
Test 25: Case Sensitivity Testing
{"LOGIN": "admin", "PASSWORD": "password"}This test changes the casing of the field names from lowercase to uppercase. It verifies whether the authentication endpoint treats property names as case-sensitive or performs automatic normalization during input processing.
Test 26: Login as Number, Password as String
{"login": 1234, "password": "password"}This test mixes data types by providing a numeric login and a string password. It helps confirm that every authentication field is validated independently according to expected data type requirements.
Test 27: Login as String, Password as Number
{"login": "admin", "password": 1234}This payload reverses the previous scenario by supplying a text-based username and a numeric password. It checks whether type validation is consistently applied to both credential fields.
Test 28: Repeated Keys
{"login": "admin", "login": "user", "password": "password"}This test contains duplicate keys within the same JSON object. Different parsers may process repeated keys differently, making this test useful for detecting inconsistencies and unexpected authentication behavior.
Test 29: Single Quotes Instead of Double Quotes
{'login': 'admin', 'password': 'password'}This test uses single quotation marks, which are not valid in standard JSON. It verifies whether the API strictly adheres to JSON specifications or incorrectly accepts non-standard input formats.
Test 30: Only Special Characters
{"login": "@#$%^&*", "password": "!@#$%^&*"}This test uses credentials composed entirely of symbols. It evaluates how special characters are processed and ensures the authentication logic does not fail when no alphabetic characters are present.
Test 31: Unicode Escape Sequence
{"login": "\u0041\u0044\u004D\u0049\u004E", "password": "\u0050\u0041\u0053\u0053\u0057\u004F\u0052\u0044"}This test encodes credential values using Unicode escape notation. It verifies proper decoding by the parser and ensures authentication behaves consistently regardless of encoding representation.
Test 32: Object Value Instead of String
{"login": {"$oid": "507c7f79bcf86cd7994f6c0e"}, "password": "password"}This test places an object containing an identifier-like value into the login field. It is often used to identify improper deserialization handling and NoSQL-style injection risks.
Test 33: Undefined Values
{"login": undefined, "password": undefined}This payload uses the JavaScript keyword undefined, which is not valid JSON. It tests whether the parser correctly rejects unsupported values instead of attempting to interpret them.
Test 34: Extra Nested Objects
{
"login": "admin",
"password": "password",
"extra": {
"key1": "value1",
"key2": "value2"
}
}This test combines valid credentials with additional nested data structures. It evaluates how the application handles complex, unexpected information included with authentication requests.
Test 35: Hexadecimal Values
{"login": "0x1234", "password": "0x5678"}This test uses strings formatted as hexadecimal values. It checks whether such inputs are treated purely as text or undergo unwanted numeric interpretation within the authentication process.
Test 36: Extra Characters After Valid JSON
{"login": "admin", "password": "password"}@@@@@@}This test appends invalid characters after an otherwise valid JSON object. It verifies that the parser refuses malformed payloads and does not ignore trailing content.
Test 37: Only Keys Without Values
{"login":, "password":}This payload contains field names with missing values. It intentionally violates JSON syntax and helps ensure the endpoint properly rejects incomplete object definitions.
Test 38: Control Characters
{"login": "ad\u0000min", "password": "pass\u0000word"}This test inserts a null control character into the credential values. It examines whether the application properly sanitizes control characters and avoids truncation or parsing anomalies.
Test 39: Long Unicode Strings
{"login": "\u0061"*10000, "password": "\u0061"*10000}This test combines Unicode encoding with extremely large input sizes. It assesses both character decoding functionality and system behavior under unusually large authentication payloads.
Test 40: Newline Characters in Strings
{"login": "ad\nmin", "password": "pa\nssword"}This test injects newline characters into credential values. It evaluates how line breaks are stored, validated, logged, and processed by backend systems involved in authentication.
Test 41: Tab Characters in Strings
{"login": "ad\tmin", "password": "pa\tssword"}This payload contains tab characters within usernames and passwords. It helps identify normalization issues and ensures whitespace control characters do not interfere with authentication logic.
Test 42: HTML Content in Strings
{"login": "<b>admin", "password": "password"}This test introduces HTML formatting tags as part of a credential value. It verifies that such content is handled as plain text and does not create rendering or cross-site scripting concerns.
Test 43: JSON Injection in Strings
{"login": "{\"injection\":\"value\"}", "password": "password"}This payload embeds JSON content inside a string value. It checks whether the application safely treats the embedded JSON as ordinary text instead of attempting additional parsing.
Test 44: XML Content in Strings
{"login": "<user>admin</user>", "password": "<pass>password</pass>"}This test uses XML-like structures within credentials. It confirms that XML content does not trigger alternate parsing behavior and is handled consistently as simple string input.
Test 45: Combination of Letters, Numbers, and Symbols
{"login": "ad123min!@", "password": "pa55w0rd!@"}This test reflects realistic credential patterns commonly used by end users. It ensures that complex but valid credentials containing multiple character categories are processed correctly.
Test 46: Floating Numbers as Strings
{"login": "123.456", "password": "789.123"}This test uses decimal numbers represented as strings instead of actual numeric values. It verifies whether the authentication system treats these values as plain text credentials and avoids performing unintended numeric conversions.
Test 47: Multilingual Input (English and Hindi)
{"login": "adminप्रयोक्ता", "password": "passwordपासवर्ड"}This test combines English and Hindi characters within the same credential values. It evaluates the application’s internationalization support and ensures that multilingual user credentials are processed without encoding issues or character corruption.
Test 48: Non-ASCII Characters
{"login": "∆admin∆", "password": "∆password∆"}This test includes non-ASCII Unicode symbols within the credentials. It helps verify that the authentication system properly supports extended character sets and does not restrict input to standard English characters only.
Test 49: Single Character Keys and Values
{"l": "a", "p": "p"}This test uses abbreviated key names instead of the expected login and password fields. It determines whether the API strictly validates field names and rejects incomplete or non-standard request formats.
Test 50: Environment Variable References
{"login": "${USER}", "password": "${PASS}"}This test submits values that resemble environment variable placeholders. It checks whether the application performs unintended variable substitution or safely processes the placeholders as ordinary strings.
Test 51: Backslashes in Strings
{"login": "ad\\min", "password": "pa\\ssword"}This test places backslash characters within credential values. It evaluates escaping behavior and ensures that path-like strings or escape sequences do not interfere with validation and authentication logic.
Test 52: Long String of Special Characters
{"login": "!@#$%^&*()"*1000, "password": "!@#$%^&*()"*1000}This test creates extremely large strings composed entirely of special characters. It assesses how the application handles oversized symbol-heavy inputs and whether length restrictions are correctly enforced.
Test 53: Empty Key Name
{"": "admin", "password": "password"}This test contains an empty string as a JSON key. It verifies that the API validates request structure properly and does not attempt to interpret unnamed fields during authentication processing.
Test 54: JSON Injection in Key
{"{\"injection\":\"value\"}": "admin", "password": "password"}This test places JSON-formatted content inside a field name rather than a value. It examines whether the application safely handles unusual keys and prevents unexpected parsing behavior.
Test 55: Quotation Marks Inside Strings
{"login": "\"admin\"", "password": "\"password\""}This payload includes quotation marks as part of the credential values. It helps determine whether special punctuation inside strings is correctly escaped and processed without affecting parsing or validation.
Test 56: Nested Arrays
{"login": [["admin"]], "password": [["password"]]}This test introduces multiple levels of array nesting instead of simple string values. It verifies that complex data structures are not mistakenly accepted as valid credentials.
Test 57: Deeply Nested Objects
{
"login": {
"username": {
"value": "admin"
}
},
"password": {
"password": {
"value": "password"
}
}
}This test uses deeply nested object hierarchies for credential values. It evaluates deserialization behavior and ensures that authentication input validation remains effective regardless of nesting depth.
Test 58: Numeric Keys
{123: "admin", 456: "password"}This test replaces conventional string field names with numeric keys. Since valid authentication requests require specific key names, the test checks whether schema validation is implemented correctly.
Test 59: Greater Than and Less Than Symbols
{"login": "admin>1", "password": "<password"}This test includes comparison symbols commonly associated with markup languages and scripting. It verifies that these characters are handled safely and do not create rendering or encoding problems.
Test 60: Parentheses in Credentials
{"login": "(admin)", "password": "(password)"}This test uses credential values wrapped in parentheses. It confirms that punctuation characters are accepted as ordinary text and do not alter application behavior during authentication.
Test 61: Credentials Containing Slashes
{"login": "admin/user", "password": "pass/word"}This test introduces forward slash characters into both the login and password fields. It verifies that path-like strings are processed correctly and do not trigger unintended URL, file path, or routing behavior within the application.
Test 62: Credentials Containing Multiple Data Types
{
"login": ["admin", 123, true, null],
"password": [
"password",
123,
false,
null,
{"password": "password"}
]
}This test combines strings, numbers, Boolean values, null values, arrays, and objects within the credential fields. It evaluates the application’s ability to validate complex payload structures and reject inputs that do not conform to the expected authentication schema.
Test 63: Escape Sequences
{"login": "admin\\r\\n\\t", "password": "password\\r\\n\\t"}This payload contains carriage return, newline, and tab escape sequences. It helps verify whether escape characters are handled safely during parsing, logging, storage, and authentication processing.
Test 64: Curly Braces in Strings
{"login": "{admin}", "password": "{password}"}This test includes curly brace characters inside the credential values. Since braces often have special meaning in programming languages and template engines, the test ensures they are treated as ordinary text.
Test 65: Square Brackets in Strings
{"login": "[admin]", "password": "[password]"}This test uses square brackets within login credentials. It verifies that the authentication system does not mistakenly interpret bracketed content as arrays or structured data.
Test 66: Strings with Only Special Characters
{"login": "!@#$$%^&*()", "password": "!@#$$%^&*()"}This test uses credentials made entirely of special symbols. It examines how the validation layer handles symbol-only values and ensures that unusual but technically valid strings do not cause parsing issues.
Test 67: Strings with Control Characters
{"login": "admin\b\f\n\r\t\v\0", "password": "password\b\f\n\r\t\v\0"}This payload contains multiple control characters, including backspace, form feed, newline, carriage return, tab, vertical tab, and null characters. It helps identify weaknesses in input handling, character sanitization, and logging mechanisms.
Test 68: Null Characters in Strings
{"login": "admin\0", "password": "password\0"}This test appends a null character to credential values. Historically, null bytes have caused truncation and parsing problems in various systems, making this an important robustness and security test.
Test 69: Exponential Numbers as Strings
{"login": "1e5", "password": "1e10"}This test uses values that resemble scientific notation but are provided as strings. It verifies that the authentication service treats them as plain text and does not perform automatic numerical interpretation.
Test 70: Hexadecimal Numbers as Strings
{"login": "0xabc", "password": "0x123"}This test submits hexadecimal-looking values in string format. It evaluates whether the application incorrectly converts or processes these values as numbers rather than user-provided text.
Test 71: Leading Zeros in Numeric Strings
{"login": "000123", "password": "000456"}This test checks how the authentication system handles numeric-looking strings that contain leading zeros. It ensures that values remain unchanged and are not normalized or reformatted unexpectedly.
Test 72: Multilingual Input (English and Korean)
{"login": "admin관리자", "password": "password비밀번호"}This test combines English and Korean text in the same credential fields. It verifies support for multilingual users and ensures proper Unicode handling throughout the authentication workflow.
Test 73: Extremely Long Keys
{"a"*10000: "admin", "b"*10000: "password"}This test uses excessively large key names instead of normal JSON field names. It evaluates schema validation, parser limits, memory handling, and the application’s resilience against oversized request structures.
Test 74: Extremely Long Unicode Strings
{"login": "\u0061"*10000, "password": "\u0062"*10000}This test sends very large Unicode-based credential values. It combines character decoding and stress testing to assess performance, memory usage, and input-length restrictions.
Test 75: Strings with Semicolons
{"login": "admin;", "password": "password;"}This test places semicolons within credential values. Semicolons are commonly associated with command syntax and database statements, making this test useful for verifying that special punctuation is processed safely as plain text.
Test 76: Strings with Backticks
{"login": "`admin`", "password": "`password`"}This test places backtick characters around the credential values. Backticks are often used in command shells, scripting languages, and template engines. The test verifies that these characters are treated as ordinary text and do not trigger special processing.
Test 77: Strings with Plus Sign
{"login": "admin+", "password": "password+"}This test includes plus signs within the login and password fields. It ensures that the authentication system properly preserves and processes plus characters without interpreting them as encoding or arithmetic operators.
Test 78: Strings with Equal Sign
{"login": "admin=", "password": "password="}This test uses equal signs at the end of credential values. Since equal signs frequently appear in encoded strings and configuration data, this test verifies that they are handled safely as part of the credential text.
Test 79: Strings with Asterisk Symbol
{"login": "admin*", "password": "password*"}This test introduces asterisk characters into credentials. As asterisks are commonly used as wildcards in searches and pattern matching, the application should ensure they remain simple text values.
Test 80: JSON Containing JavaScript Code
{"login": "admin<script>alert('hi')</script>", "password": "password"}This test embeds JavaScript code within the login field. It is designed to verify that potentially executable content is stored and processed as plain text and cannot be executed within user interfaces or application outputs.
Test 81: Negative Numbers as Strings
{"login": "-123", "password": "-456"}This test uses negative numbers represented as strings. It checks whether the authentication system treats these values purely as text rather than converting them into numeric values.
Test 82: Values as URLs
{"login": "https://admin.com", "password": "https://password.com"}This test submits URL-formatted values as credentials. It verifies that web addresses are accepted or rejected according to business rules without causing unexpected URL parsing behaviour.
Test 83: Strings with Email Format
{"login": "admin@admin.com", "password": "password@password.com"}This test uses email-formatted strings for both fields. Many systems allow email addresses as usernames, making this an important scenario for validating email-based authentication workflows.
Test 84: Strings with IP Address Format
{"login": "192.0.2.0", "password": "203.0.113.0"}This test uses values that resemble IPv4 addresses. It checks whether numeric-dot formats are handled correctly and do not cause parsing or validation inconsistencies.
Test 85: Strings with Date Format
{"login": "2023-08-03", "password": "2023-08-04"}This test submits credentials that resemble calendar dates. It verifies that date-like strings are treated as ordinary credentials and are not subject to automatic formatting or conversion.
Test 86: JSON with Exponential Values
{"login": 1e+30, "password": 1e+30}This test uses actual exponential numeric values instead of strings. It helps verify type validation rules and confirms that extremely large numbers are not accepted where string credentials are expected.
Test 87: JSON with Negative Exponential Values
{"login": -1e+30, "password": -1e+30}This test provides very large negative exponential numbers. It evaluates how the parser and validation layer handle extreme numeric values supplied in credential fields.
Test 88: Zero Width Space in Strings
{"login": "admin", "password": "password"}This test inserts the Unicode Zero Width Space (U+200B) into credential values. Because the character is invisible to users, the test helps identify normalization, validation, and impersonation-related issues.
Test 89: Zero Width Joiner in Strings
{"login": "admin", "password": "password"}This test includes the Unicode Zero Width Joiner (U+200D). Similar to invisible spaces, this character can affect string comparison and identity matching, making it useful for testing Unicode normalization behavior.
Test 90: Extremely Large Numbers
{"login": 12345678901234567890, "password": 12345678901234567890}This test submits very large integer values exceeding normal numeric ranges used in many applications. It helps identify overflow issues, precision loss, and incorrect type handling during request processing.
Test 91: Strings with Backspace Characters
{"login": "admin\b", "password": "password\b"}This test places backspace control characters inside credential values. It examines how logging systems, parsers, and validation mechanisms react to non-printable characters embedded within strings.
Test 92: Emoji in Strings
{"login": "admin😀", "password": "password😀"}This test incorporates emoji characters into credentials. It verifies UTF-8 support and ensures that modern Unicode characters can be processed, stored, and compared correctly.
Test 93: JSON with Comments
{/*"login": "admin", "password": "password"*/}This test introduces comment syntax into the JSON payload. Since comments are not part of the official JSON specification, the parser should reject the request rather than attempting to process it.
Test 94: Base64 Encoded Values
{"login": "YWRtaW4=", "password": "cGFzc3dvcmQ="}This test uses Base64-encoded strings instead of plain-text credentials. It evaluates whether the application performs any automatic decoding and how encoded values are handled during authentication.
Test 95: Null Byte Character
{"login": "admin\0", "password": "password\0"}This test injects a null byte at the end of the credential values. Null bytes have historically caused truncation and filtering bypass issues in certain systems, making them valuable for security testing.
Test 96: Credentials in Scientific Notation
{"login": 1e100, "password": 1e100}This test uses extremely large scientific notation values as credential inputs. It checks parser behavior, numeric limits, and validation controls when exceptionally large numbers are provided.
Test 97: Strings with Octal Values
{"login": "\141\144\155\151\156", "password": "\160\141\163\163\167\157\162\144"}This test represents credential values using octal escape sequences. It verifies whether the application correctly interprets encoded character representations and treats them consistently with equivalent plain-text values.
