How to fix SQL injection, XSS, resource exhaustion and deserialization flaws in embedded firmware

Last updated: 2026-10-29

Device web UIs and local management APIs are small web applications, so they inherit classic web weaknesses: SQL injection (CWE-89), cross-site scripting (CWE-79), resource exhaustion (CWE-400) and insecure deserialization (CWE-502). All four MITRE pages read 2026-10-29. Each is a distinct root cause with its own fix, covered in its own section below — detect, fix, verify, ship and disclose steps follow after.

SQL injection (CWE-89)

A device's local database — often SQLite, backing configuration, logs or a captive-portal user list — is queried with a string built from request input. MITRE's CWE-89: the product "constructs all or part of an SQL command using externally-influenced input... but does not neutralize" special characters in it. Fix: switch every query touching request input to prepared statements / parameterized queries, where, per OWASP, "bound values [are treated] as data rather than SQL syntax" — never build SQL by string concatenation, and don't rely on manual escaping as a substitute. For structural elements a parameter can't bind (table or column names, sort order), map the request's choice to a small, fixed, application-owned set of allowed tokens and reject anything else.

Cross-site scripting (CWE-79)

A status page, log viewer, or any page that echoes a device name, SSID or other user-supplied string back into HTML without encoding is vulnerable. MITRE's CWE-79: the product "does not neutralize... user-controllable input before it is placed in output that is used as a web page." Fix: encode every variable for the specific context it's rendered into — HTML entity encoding for text content, attribute encoding for HTML attributes, JavaScript-string encoding plus the surrounding HTML encoding for script contexts, URL encoding for URL parameters — using your web framework's auto-escaping templates rather than hand-written string concatenation. Prefer safe DOM methods (textContent, setAttribute()) over innerHTML in any client-side JavaScript. Set the HttpOnly flag on session cookies as defense in depth, and treat a Content-Security-Policy as an additional layer, not the primary fix.

Resource exhaustion (CWE-400)

An embedded device has a fixed, usually small, memory and CPU budget, which makes it more vulnerable than a server to a flood of connections, an uncapped log or upload size, or a request that triggers unbounded work. MITRE's CWE-400: the product "does not properly control the allocation and maintenance of a limited resource," typically leading to denial of service, and in some designs to an insecure "fail open" state once a resource limit is hit. Fix: design explicit limits into the architecture — a maximum number of concurrent connections or sessions, a maximum request/upload size, a maximum log or queue size — and rate-limit requests per source rather than leaving any resource uncapped. Just as important: make every resource-allocation failure path fail into a safe state (reject the request, keep existing sessions intact) rather than an undefined one that could itself be a security hole.

Insecure deserialization (CWE-502)

A management API or companion-app protocol that deserializes a structured object (a session token, a configuration blob, an IPC message) from untrusted input is vulnerable if the deserializer will instantiate arbitrary types from that input. MITRE's CWE-502: the product "deserializes untrusted data without sufficiently ensuring that the resulting data will be valid," which can corrupt application state or, through chained method calls, lead to code execution. Fix: per OWASP's top recommendation, avoid native/binary deserialization of untrusted data entirely — use a plain data format (JSON, protobuf with a fixed schema) instead of a language's native object-serialization format. Where a native format can't be avoided, enforce a strict allowlist of the specific types allowed to deserialize, and verify an integrity signature on the serialized blob before deserializing it at all.

Detect, across all four

Map every endpoint in the device's web UI and management API that touches a local database, renders user-supplied text into HTML, accepts a request with no size/rate limit, or deserializes a structured object from the network.
Fuzz each one with the matching payload class: SQL metacharacters and boolean/time-based injection probes for database-backed endpoints; HTML/JS injection strings for anything echoed into a page; oversized/burst requests for anything unbounded; crafted serialized blobs for deserialization endpoints.
Run static analysis with rule coverage for CWE-89, CWE-79, CWE-400 and CWE-502 across the web UI and API codebase.

Verify

Re-test the original proof-of-concept payload against the patched endpoint, plus at least one variant per class (a different injection encoding, a different resource-exhaustion vector, a different deserialization gadget) to confirm the fix isn't narrowly scoped to the exact reported case.
For resource-exhaustion fixes specifically, load-test the patched limit under a sustained flood and confirm the device degrades into the intended safe state rather than crashing or exposing an unintended bypass.

Ship an update, and disclose via PSIRT

Distribute the fix through your normal signed-firmware update channel, and use your firmware SBOM to confirm which product lines share the affected web UI or API component. Publish the advisory through your coordinated disclosure process (CVD process explained; PSIRT setup for a hardware company if you don't have one yet), and check the Cyber Resilience Act's 24-/72-hour reporting duty for EU-market products if there is evidence of active exploitation (CRA 24h/72h reporting). CISA's Secure by Design Pledge names SQL injection and cross-site scripting explicitly as example classes signatories commit to reducing; see our CISA Secure by Design guide.

SoftWSP's device and firmware assessments test local web UIs and management APIs against all four of these classes directly: see device & firmware security.

This guide summarises public MITRE CWE and OWASP guidance; it is not a substitute for a full code review and does not constitute legal advice.

Frequently asked questions

Why are these four different weaknesses covered in one guide?

SQL injection (CWE-89), cross-site scripting (CWE-79), resource exhaustion (CWE-400) and insecure deserialization (CWE-502) are distinct weaknesses with different root causes, but in embedded device firmware they share the same attack surface — the device's local web management UI and management API — and the same underlying discipline: untrusted input must be handled through a safe, structured mechanism (a parameterized query, a context-aware encoder, a resource limit, a type allowlist) rather than concatenated, rendered or deserialized directly. Each has its own section below with its own MITRE/OWASP citations.

What is SQL injection, and what is the actual fix?

MITRE's CWE-89 defines it as a product that "constructs all or part of an SQL command using externally-influenced input... but does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command." OWASP's SQL Injection Prevention Cheat Sheet is direct about the fix: "define the SQL structure separately from its data values, then bind those values through the database API" — i.e. prepared statements / parameterized queries, where "bound values [are treated] as data rather than SQL syntax." OWASP explicitly warns not to "use manual escaping as a substitute for parameter binding," since escaping rules vary by database configuration and are routinely bypassed.

What is cross-site scripting, and what is the actual fix?

MITRE's CWE-79 defines it as a product that "does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page." A device's web UI (status pages, log viewers, device-name fields echoed back into HTML) is a classic target. OWASP's Cross-Site Scripting Prevention Cheat Sheet's core rule is to encode every variable for the specific output context it lands in — HTML entity encoding, HTML-attribute encoding, JavaScript string encoding, URL encoding — rather than one generic filter, and to prefer safe DOM APIs (`textContent`, `setAttribute()`) over `innerHTML` in any JavaScript-rendered UI.

What is resource exhaustion, and what is the actual fix?

MITRE's CWE-400 (Uncontrolled Resource Consumption) is simply: "the product does not properly control the allocation and maintenance of a limited resource," most often resulting in denial of service, and in some cases a security-relevant "fail open" state when a resource limit is hit. MITRE's architecture-level mitigation is to "design throttling mechanisms into the system architecture... limit the amount of resources that an unauthorized user can cause to be expended," track and rate-limit requests per source, and — critically for embedded devices with fixed memory/CPU budgets — "ensure that all failures in resource allocation place the system into a safe posture" rather than an undefined or insecure one.

What is insecure deserialization, and what is the actual fix?

MITRE's CWE-502 defines it as a product that "deserializes untrusted data without sufficiently ensuring that the resulting data will be valid," which can let an attacker construct an object graph that corrupts application data or, via chained method calls ("gadget chains"), triggers unintended code execution. OWASP's Deserialization Cheat Sheet's top recommendation is to avoid native/binary deserialization formats for untrusted data entirely — "switching to a pure data format like JSON or XML... lessen[s] the chance of custom deserialization logic being repurposed" — and, where a native format can't be avoided, apply a strict type allowlist and verify an integrity signature before deserializing.