Skip to main content

​
Input Validation and Sanitization

Proper input validation and sanitization are critical for securing your application during the OAuth 2.0 flow and when handling data received from Mubarokah ID. This helps prevent common web vulnerabilities such as Cross-Site Scripting (XSS), injection attacks, and other issues arising from processing untrusted data.

​
Key Principles

  • Validate All External Inputs: Treat any data received from external sources as untrusted. This includes:
    • Parameters from the authorization redirect (code, state, error, error_description).
    • Data from the token endpoint response (access_token, refresh_token, scope, etc.).
    • User information received from API endpoints (/api/user, /api/user/details).
  • Server-Side Validation is Crucial: While client-side validation can improve user experience, server-side validation is essential for security as client-side checks can be bypassed.
  • Be Specific: Validate against expected formats, types, lengths, and ranges.
  • Fail Closed: If validation fails, reject the request or data, and log the incident. Do not attempt to “fix” invalid input.

​
Validation During OAuth Flow

​
Authorization Callback (redirect_uri)

When Mubarokah ID redirects the user back to your redirect_uri:

​
Token Endpoint Response

When you exchange an authorization code or refresh token for new tokens: 
<?php
// Conceptual Server-side validation for token response (PHP)
// From "Security Guidelines Enterprise" -> "🚨 Input Validation & Sanitization"
// class OAuthInputValidator
// {
//     public static function validateTokenResponse(array $tokenData): void
//     {
//         $requiredFields = ['access_token', 'token_type', 'expires_in'];
//         foreach ($requiredFields as $field) {
//             if (!isset($tokenData[$field]) || empty($tokenData[$field])) {
//                 // Log error
//                 throw new \InvalidArgumentException("Token response missing required field: {$field}");
//             }
//         }

//         // Validate token_type (case-insensitive check, then normalize)
//         if (strtolower($tokenData['token_type']) !== 'bearer') {
//             // Log error
//             throw new \InvalidArgumentException("Unsupported token type: " . $tokenData['token_type']);
//         }

//         // Validate expires_in
//         if (!is_numeric($tokenData['expires_in']) || (int)$tokenData['expires_in'] <= 0) {
//             // Log error
//             throw new \InvalidArgumentException("Invalid expires_in value: " . $tokenData['expires_in']);
//         }

//         // Optional: Validate access_token format (e.g., if it's a JWT and you need to parse it)
//         // This depends on whether the token is opaque or structured.
//         // If it's an opaque token for your client, you might just check it's a non-empty string.
//         // if (self::isPotentiallyJwt($tokenData['access_token']) && !self::isValidJWTStructure($tokenData['access_token'])) {
//         //     throw new \InvalidArgumentException('Invalid access token format (JWT structure error)');
//         // }
//     }

//     // private static function isPotentiallyJwt(string $token): bool
//     // {
//     //     return count(explode('.', $token)) === 3;
//     // }

//     // private static function isValidJWTStructure(string $token): bool
//     // {
//     //     $parts = explode('.', $token);
//     //     if (count($parts) !== 3) return false;
//     //     try {
//     //         base64_decode($parts[0], true); // Header
//     //         base64_decode($parts[1], true); // Payload
//     //         // Signature part doesn't need to be base64_decodeable by client if not verifying
//     //     } catch (\Exception $e) {
//     //         return false; // Not valid base64
//     //     }
//     //     return true;
//     // }
// }

// // Usage:
// // $tokenDataFromResponse = json_decode($responseBody, true);
// // OAuthInputValidator::validateTokenResponse($tokenDataFromResponse);
?>
The PHP code example above is conceptual and demonstrates server-side validation logic for a token response. Adapt it to your specific language and framework.

​
Validating User Information (from API responses)

  • Data Types: Validate that fields match their expected types (e.g., id is a number/string, email looks like an email, profile_picture is a URL if present).
  • Sanitize for Display: If you are displaying any user information directly in your application (especially in HTML), ensure it is properly sanitized/escaped to prevent XSS vulnerabilities. Use template engine features or libraries designed for this.
    • Example (Blade in Laravel): {{ $userData->name }} (auto-escapes)
    • Example (JavaScript, if setting innerHTML): element.textContent = userData.name; (safer than innerHTML)

​
General Best Practices

  • Use Well-Tested Libraries: Leverage existing libraries for OAuth 2.0 client flows and data validation in your chosen language/framework, as they often have built-in protections.
  • Regular Expression (Regex) Wisely: For complex string formats, use regex for validation but ensure your regex patterns are not susceptible to ReDoS (Regular Expression Denial of Service) attacks.
  • Error Handling: Implement robust error handling for validation failures. Log attempts that fail validation for monitoring and security analysis.
  • Security Headers: Implement security headers like Content Security Policy (CSP) to mitigate the impact of XSS vulnerabilities even if some unsanitized input makes it through.
By diligently validating and sanitizing all inputs, you significantly strengthen your application’s defense against common web attacks.