Malicious Compliance: The JSON-Wrapped HTML

Description

A four-panel webcomic from 'CommitStrip'. In the first panel, a female developer advises a male colleague, 'What's going on with all these divs?! You shouldn't be returning all this hard coded HTML...'. In the second panel, she explains the modern approach, 'Nowadays we send our data as a JSON object and then we integrate it into the DOM via the front-end.' The colleague seems to understand. The third panel, labeled 'LATER,' shows the male developer returning triumphantly, saying, 'Done! It was easier than I thought actually!' His colleague replies, 'Great!'. The fourth panel reveals the punchline: a screen showing a JSON response where a single key, 'html', contains a massive string of the exact same hardcoded HTML. A speech bubble clarifies his flawed logic: 'I wrapped all the Ajax responses in a JSON object like you asked!'. The comic hilariously captures the classic scenario of a junior or legacy developer following instructions literally while completely missing the underlying architectural principle - the separation of data and presentation

Common Tags

Json WebDevelopment Html Javascript Frontend DataFormats API ApplicationProgrammingInterface

Comments

Anonymous ★ Top Pick This isn't an API response; it's a server-side rendered page that's cosplaying as a JSON object for Halloween. The only thing it's decoupling is the developer from the principles of modern web architecture

Anonymous ★ Top Pick

This isn't an API response; it's a server-side rendered page that's cosplaying as a JSON object for Halloween. The only thing it's decoupling is the developer from the principles of modern web architecture
Anonymous

Congrats, team - by stuffing raw HTML into a “html” key, we’ve reinvented server-side rendering, SOAP, and an XSS vector, all elegantly wrapped in a single artisanal JSON object
Anonymous

This is exactly how we ended up with a GraphQL resolver that returns HTML strings wrapped in JSON, which the frontend then parses with regex before injecting into dangerouslySetInnerHTML - and somehow it's still in production because "it works."
Anonymous

Ah yes, the classic 'JSON as a transport layer for HTML strings' pattern - because why send structured data when you can just wrap your entire DOM in quotes and call it RESTful? This is the architectural equivalent of putting your entire codebase in a single file and calling it 'modular' because you used one export statement. The real tragedy here isn't just the misunderstanding - it's that this will probably work just fine until someone needs to actually parse that data on mobile, or cache it, or do literally anything except innerHTML it back into existence. At least when this hits production and someone opens the Network tab, the 'Preview' vs 'Response' tabs will provide hours of entertainment
Anonymous

Backend: 'JSON makes frontend easy!' Frontend reality: It's divs all the way down
Anonymous

Ask for JSON instead of HTML and someone ships { html: '<div...>' } - congrats, you just implemented contract-compliant SSR via innerHTML with a bonus XSS surface
Anonymous

“Send JSON, not HTML,” they said - so the API returns { html: "<div…>" }. Congrats: same tight coupling, more escaping, and a new MIME type, application/facepalm+json
@lytdev 5y

When you have recently completed IT-courses and immediately start creating dev memes
1. @x_Arthur_x 5y
  
  Great!
@Flam_Su 5y

Newbie. Profi encodes all to base64
1. Deleted Account 5y
  
  Always encrypt your data!! ;)
  
  @qtsmolcat 5y
  
  Best obfuscation: 1) no comments 2) variable and function names that are gibberish 3) random shit that doesn't do anything
  
  Deleted Account 5y
  
  No, best obfuscation is a python oneliner
  
  @qtsmolcat 5y
  
  😮
2. @ManveVitality 5y
  
  What about to encode every key and value to base 64, then put encoded data into JSON and encode this JSON to base64? 🌚
@qtsmolcat 5y

Yas