Escaping, Encoding, and Boundaries

Escaping, encoding, and boundaries sound like small plumbing details, right up until your app starts printing JavaScript popups that you never wrote. If you ship code on the web, this topic is not trivia. It is daily survival.

Apple just pushed iOS 7 and every team I know is racing to refresh their apps. New styles. New APIs. In the rush, the boring parts get skipped. That is where injection lives. Quiet, patient, expensive.

Escaping is how you take data and make it safe for a specific output context. You pick a context, you transform the data so the parser sees it as text, not as code. The key word is context.

Encoding maps text to bytes. Think UTF 8, Latin 1, and friends. Encoding does not make data safe by itself. It just decides how characters become bytes and back again. Confuse these two and you get ghosts in your app.

There is also sanitization, where you remove or rewrite risky input. That is useful, but it is not a replacement for proper output escaping. You do not scrub data once and call it a day. You escape for each place you send it.

A boundary is any point where data crosses into a new parser or a new trust level. Browser DOM. SQL engine. Shell. Mail client. JSON parser. Each one has its own grammar and rules. Each one needs a matching strategy.

If you treat all boundaries the same, you invite cross site scripting, SQL injection, and worse. When people say trust boundary, this is what they mean. Find the edges where data stops being yours and starts being code to someone else.

Because one mistake is all it takes. An unquoted HTML attribute. A string builder in a SQL query. A JSON blob shoved straight into inline script. Hidden assumptions pile up and attackers live for that one moment where assumptions meet reality.

Encoding makes this messier. Mix encodings or mislabel a response and you can create turn to the dark side characters that bypass your checks. A byte that looks harmless in one encoding can be special in another. That is how filters get fooled.

Think in slices, not in one big web blob. You have at least these contexts:

Each one has its own escape rules. HTML uses entities. JavaScript uses backslash escapes inside quotes. URLs use percent encoding. SQL should not rely on escaping at all. Use prepared statements. Same for shell, pass arguments to the process API instead of stitching strings.

For HTML text, convert the special five. That is less than, greater than, ampersand, quote, and apostrophe when needed. For HTML attributes, always quote and escape inside the quotes. Do not ever use unquoted attributes with user data.

For JavaScript, place data in a quoted string and escape with the language rules. Better yet, do not build script with data at all. Put data in data attributes or in a JSON response and let your code read it.

For URLs, encode each component separately. Path segments, query keys, and values each get their own encoding step. Do not hand mix them. For CSS, avoid injecting data into style blocks. If you must, use safe values only. Never pipe raw text into a URL function in CSS.

For SQL, move to parameterized queries or your ORM bindings. That is the line between you and the weekend pager. No string join. No string format. Parameters only.

Lots of modern templates ship with auto escape turned on. Rails does this. Django does this. Twig and Jinja do this. The idea is simple. You print variables and they get HTML escaped by default. That blocks a big chunk of cross site scripting by design.

Templating still needs care. Inside event handler attributes, inside style attributes, and inside script tags, default HTML escaping is not enough. Switch to safer patterns. Bind events with JavaScript, not with inline handlers. Move styles to classes. Keep script tags free of data.

Mustache and Handlebars escape by default. The triple mustache turns off escaping. That one is a foot gun. Only use it for content you already marked as safe on the server. Angular is getting traction and has its own binding rules. The short version is this. Prefer bindings that do not interpret HTML unless you trust the source fully.

On the client, jQuery has .text and .html. One treats data as text, the other as HTML. Choose the first one by default. On Node with Express, the usual views like EJS or Jade escape by default, but the same caveats apply when you jump into script or style zones.

JSON is for data, not for code. Use JSON.stringify on the client and the server serializer on the server. Serve with application/json. Never call eval on JSON. Do not push JSON straight into an inline script block. If you must render JSON inside HTML, wrap it in a script tag with a data type the browser does not run, then parse it safely.

JSONP still exists. Treat it like a loaded cross domain weapon. Only use it with endpoints you trust completely. Better approach is CORS with strict rules.

When encodings differ, characters can shape shift. A byte that is a quote in one charset might be plain text in another. If your database, your app server, and your templates disagree on charsets, an attacker can smuggle control characters through the cracks.

Pick UTF 8 end to end. Set your HTTP headers. Set your meta tag early in the head. Configure your database connection and tables. Make sure logs and queues also speak the same charset. Then test with weird characters. Emoji. Accents. Right to left marks. If your app handles those cleanly, you are on the right track.

Build a simple map. Mark sources like form inputs, cookies, headers, database rows. Mark sinks like HTML, script, style, SQL, shell, file system. For each path from a source to a sink, note the encoder or the binding that makes it safe.

Keep data as data for as long as possible. Escape only at the final step where you render or send. Do not escape early, store, and then forget. That leads to double escaping and broken output. Late and context specific is the rule.

WebViews are everywhere. Android and iOS wrappers load your pages inside apps. If you bridge JavaScript to native, treat that bridge like a root account. Do not expose broad methods. Only expose functions you need, and gate them with origin checks or tokens.

On iOS, watch what you put into UIWebView and any custom URL schemes. On Android, keep an eye on addJavascriptInterface on older devices. If a page is untrusted, do not give it a bridge at all. The safest bridge is no bridge.

Tools help you catch the obvious. OWASP ZAP and Burp for poking at the app. Brakeman for Rails. ESLint or JSHint for client code quality. Static checks are a safety net, not a parachute. You still need to build with the right patterns.

Monitoring also matters. Add Content Security Policy where you can to catch and block script injection. Modern browsers support it, and it makes some whole classes of bugs harder to exploit. Start with a report only mode and study the noise.

Rendering user names in page titles without escaping. Building a confirm dialog by splicing user text into an onclick attribute. Writing a SQL query with string join because the ORM was awkward. Shipping a WebView that loads a remote page with full native bridge access.

None of these feel fancy. They are the kind of five minute choices you make at the end of a sprint. This is why you write down rules and bake them into your templates and libraries. Save your team from the easy mistake.

Skip the scary slides and jump to muscle memory. Here is our print helper. It escapes by default. Here is our SQL helper. It only takes parameters. Here is our URL builder. It encodes segments for you. Build guardrails into the codebase.

Then share a small test suite with nasty strings. Angle brackets. Quotes. Script tags. Unicode confetti. Run the suite often. Make it part of your review culture. Bad patterns should stand out like a red flag.

Data is not code. The moment you forget that, you hand control to whoever can shape the data. Escaping, encoding, and boundaries are a set of habits that keep that line sharp. They are not extra polish. They are the seat belt.

We love new frameworks and fresh UI kits. Ship the shiny. But keep one eye on the boring parts. They are the parts that keep the rest of your work from falling apart in the hands of real users and curious strangers.

Pick UTF 8. Escape at the last moment per context. Use parameters, not string join. Avoid inline handlers and inline script with data. Let templates auto escape. Test with weird characters. Add CSP to watch and block.

Do this and most injection tries will bounce. Do it consistently and you will sleep better when the next patch Tuesday rolls in and your feed is full of zero days. Boring wins. That is the point.