Web application security in your code

Why this area matters

Injection and its relatives — SQL injection, cross-site scripting, server-side template injection, unsafe deserialization — have been in the OWASP Top 10 since it began, and CWE-79, CWE-89 and CWE-78 sit near the top of the CWE Top 25 year after year. One exploitable sink can expose a whole database or let an attacker run code on your server.

They are also where pattern scanners are noisiest. A rule sees a string-built query or a raw-HTML sink, but not whether the value came from a request, a constant or a value already bound as a parameter. Teams end up re-reviewing the same safe code on every scan and miss the one hit that matters.

OpenRouting runs Semgrep to surface candidates, then routes each finding to a specialist review agent that traces where the value comes from and whether the framework already neutralizes it, and returns a verdict, a confidence score and a fix.

What goes wrong in real applications

• Query injection

  Request data concatenated into SQL or NoSQL queries can change what the query does. The result is data theft, data tampering or an authentication bypass.

• Server-side template injection

  When user input becomes part of a template's source instead of its data, the template engine evaluates it. Depending on the engine, that can mean reading server data or running code.

• Cross-site scripting

  Untrusted text rendered as HTML or script runs in other users' browsers. Sessions can be stolen and actions taken in the victim's name.

• Unsafe deserialization

  Loading pickle, Java serialization or unsafe YAML from an untrusted source can instantiate arbitrary objects. In many runtimes that leads directly to code execution.

• Business-logic flaws

  Missing checks on state, quantity or sequence — refunding twice, skipping a payment step, negative quantities — that no input filter catches. These need someone to read the flow, not just the sink.

Sample: the risky pattern and the fix

from flask import request, render_template_string

@app.get("/greet")
def greet():
    name = request.args.get("name", "friend")
    # User input becomes part of the template source.
    template = f"<h1>Hello {name}!</h1>"
    return render_template_string(template)

from flask import request, render_template_string

@app.get("/greet")
def greet():
    name = request.args.get("name", "friend")
    # Fixed template; user input is passed as data and autoescaped.
    return render_template_string("<h1>Hello {{ name }}!</h1>", name=name)

The f-string pastes the request parameter into the template before Jinja sees it, so Jinja evaluates whatever the user sent as template syntax. In the fix the template is a constant and the name is passed as a variable, so Jinja treats it as text and HTML-escapes it.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• Request data flowing into SQL/NoSQL queries, templates, shell commands and deserializers (Semgrep rules, then agent review)
• Framework escape hatches: raw(), text(), dangerouslySetInnerHTML, v-html, autoescape off
• Template rendering from strings built with user input
• pickle, yaml.load, ObjectInputStream and unserialize on data that crosses a trust boundary
• Whether a flagged value is a constant, server config or already bound as a parameter (the usual false-positive signal)

Scope and limits

• It reads source code; it doesn't crawl or attack your running site, so issues that only appear at runtime (a misconfigured WAF, a proxy rewriting headers) are out of view.
• Business-logic flaws are reviewed when a finding points at them, but no static scan can prove a multi-step workflow is correct.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• SQL injection — Decides whether attacker-controlled input actually reaches a SQL or NoSQL query unparameterized.
• Cross-site scripting (XSS) — Checks whether untrusted data is rendered into HTML or JavaScript without contextual encoding.
• Command & code injection — Checks whether user input reaches a shell, eval or template-evaluation sink.