Translation Files: A Security Risk? - Blog

Avoid Executable Formats: Don't allow formats that can contain executable code (e.g., .po files with arbitrary binary data). Stick to simple text-based formats like JSON or YAML.
Schema Validation: If using JSON or YAML, define a strict schema and validate all submitted translation files against it. # Example JSON Schema snippet: { "type": "object", "properties": { "greeting": {"type": "string"} }, "required": ["greeting"] }

TL;DR

User-provided translation strings can be a serious cyber security risk. Malicious code can be hidden within these strings, leading to cross-site scripting (XSS), remote code execution (RCE) or other attacks. This guide explains how to identify and mitigate this threat.

Understanding the Problem

Many applications allow users to contribute translations for different languages. While helpful for global reach, these submissions aren’t always vetted properly. Attackers can exploit this by injecting harmful code into translation strings that will be executed when displayed to other users.

Solution: Protecting Against Malicious Translations

Input Validation & Sanitisation: This is your first line of defence.
- Character Restrictions: Limit the allowed character set. Don’t allow HTML tags or special characters unless absolutely necessary and properly escaped (see step 3).
- Length Limits: Impose reasonable length limits on translation strings to prevent overly long, potentially malicious inputs.
- Regular Expression Filtering: Use regular expressions to block common attack patterns. For example, you might block tag" if re.search(r'