HTMX IS INSECURE (XSS) | Prime News
ฝัง
- เผยแพร่เมื่อ 4 ส.ค. 2023
- Recorded live on twitch, GET IN
/ theprimeagen
Reviewed Twitter accounts:
-- HTMX.org | / htmx_org
-- Nathan James | / nsjames_
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact - วิทยาศาสตร์และเทคโนโลยี
You should never trust anything that comes into your backend from the outside. Frontend validation of input is great for providing error messages without needing a round-trip to the backend, but your backend should always assume incoming data is hostile.
It was more about the frontend trusting what is coming from the backend. HTMX is taking data from the backend and changing the HTML without validation. (If you can't trust your backend you may need to rethink it... So you should do what you say and filter for XSS attacks when outside data comes in to your backend not only for SQL injections)
I agree. FE validation for UX, BE validation for security and data integrity.
But, but Google Web Integrity will solve this!
(Yeah, this is sarcasm)
Yep, that's my rule of thumb, front end validation is an UX thing, backend validation is a security thing.
@@lubricustheslippery5028 This isn't a new problem, you would do this no matter what framework you're using, so using this as an argument against HTMX is fallacious. Of course if you can't trust 3rd-party content (untrusted server), you're going to sanitize it before injecting it as HTML into your page; that's just common sense. If the argument is that it's too easy to not realize everything is injected, I would say that's a skill issue, not an inherent flaw of the system. If I give you a knife and you cut yourself with it, that's not an inherent flaw in the knife, that's your inability to use it properly.
When I learned webdev, it was straight PHP, no JS. That's why I like HTMX. It's like coming home. I can render everything on the server again, but now I don't have to send whole pages back. This whole "You didn't sanitize your form inputs" kerfuffle is weird. It's the web, literally anyone can curl anything at any of your rest endpoints. You should ALWAYS be server-side sanitizing. Anyone that thinks the remote client is trustworthy should watch multiplayer game development.
What I love about HTMX is the potential to do both client and server side sanitization from the same document object model, I've experimented with this in the past using HTML5's pattern and required, it's great to see this approach being embraced
So why not use php? Let me guess you have ptsd from being bullied.
@@coldestbeer php isnt as bad as people say it is, but its not good. also htmx lets you use any language on the backend, so you can use the one that actually fits youre problem best, instead of php or js for no good reason
@sircalvin but if you're using php & use laravel for backend framework, you can just use blade templates & you got htmx.
Yeah exactly, people often forget people can just completely ignore your client.
Always check on the server. On the client is just for convenience.
Seeing React developers discover how the web works and being spooked by things that have been solved for more than two decades is super entertaining.
Yup, as a Reactjs dev i needs to learn more.
But I know every tool is great whether jQuery, php, Reactjs or Htmx. It is always devs fault not the tools fault.
Soooo much this. I pulled out of ui work years ago to focus on back-end. I came back to ui to learn the latest fads (React, Angular, etc...). I'm mostly disgusted with the beautifully overloaded javascript. We were doing much cleaner, faster, and responsive web sites with well designed AJAX 2 decades ago. That experience showed me why most "modern" web sites have become so trashy.
@@shrin210well, I mean some "tools" are inherently insecure.
"look at all these jrs, clearly unlike me: a senior"
@@RamkrishanYT he's not wrong though.
Did you know that if you leave yourself vulnerable to XSS you’re vulnerable to XSS?
Right!?! And this just in, sql is insecure because if you leave yourself vulnerable to Sql injection, you're vulnerable to Sql injection!!!
Right, like what is the argument against SQL, SQL injection reigned as the #1 cybersecurity exploit for almost 20 years only dropping to #3 in 2020, the lesson seems to be sanitize the inputs.
@@DropShotPat DONT USE SQL!!! DONT YOU KNOW ABOUT SQL INJECTION?
I can see devs reading this statement, and reacting like the mitchell and webb comedy sketch 'A Bigger Spoon'
@@DropShotPat The lesson is not "sanitize the inputs" in case of SQL injection. Why do I hear this so many times? It's not it. The lesson is: "Use proper prepared statements so parts of user input can't be executed as SQL". Users can still enter shit like "WHERE 1=1;" in "email" field, and it will simply be stored in DB table as plain text, never treated as code.
HTMX is too secure. We need HTMXSS
"You can get XSS if you reflect raw user input back" really isn't the point they think it is.
Hacking your self with copy paste.
@@fulconandroadcone9488 please learn basics of reflected xss :)
Complexity intruduced by interactivity was the main reason we switched to frameworks from template and server rendered html. HTMX solves it. Time to move back to old days.....
HTMX will be loved more by backend devs (like me) beacuse we will have more control.
Just add something similar to htmx to html6 and let the browser handle it. There's no reason JavaScript should be a requirement to use a modern website
If frontend sanitizes, nothing stops me from donning a “I’m a frontend” t-shirt and tell the backend there’s “gullible” written on its lungs.
Hey backend the gay says what!!
Backend: what?..
...
oh
Obviously the backend needs to sanitise, but some people aren't aware that frontend sanitisation does actually provide a defence in depth security benefit in niche cases where an attacker has restricted abilities e.g. to mess with user input.
And of course there's a more obvious defence in depth benefit to sanitising what you get back from the backend before you attempt to render it.
Backend sanitizes data it needs to store and present authoritatively. Frontend sanitizes data it fetches and needs to present authoritatively. All for the same t-shirt wearing, lung drawing reason.
And IMO, frontend sanitization when sending data doesn’t really restrict attacker, it merely filters out script kiddies and “too eager to modify forms” single neuron bastards like me. Frontend does shine when one needs to _structure_ input data close to the point of truth though.
If you "sanitize" on front, you don't sanitize the input, you sanitize the output. Imagine the following case: data inputed script alert('whatever'); script (I removed the tags notation because I don't know how much youtube would read into that). Lets say now that is not sanitized on back, and you save it exactly like that (not a good idea, but to exemplify why front sanitize works vs xss if done corectly). Now you read the data (well... another user does and it goes to his browser in a comment, listing, whatever). If the front just removes the tags for example (not a perfect sanitization, but again, example), that becomes a simple useless ugly string. The attacker can ofc disable that sanitization BUT he can only do that for himself (because for other users, you control the interface). So yes, you can sanitize the output on front as a counter to xss. Specifically to xss.
The same kind of people who made an insecure site in php 5, years ago are the same kind of people who now don't
understand HTMx and think it's insecure.
Skill Issue
"But the X is scary"
as i always said "it's not the language it's the monkey between the chair and the keyboard"
@@SXsoft99 htmx is not a language
@@asdqwe4427 Yea sure, next thing you will say HTML and CSS are not real langue next? They are real and very much ready to hurt your feelings.
@@SXsoft99it's a PEBCAK
This is hilarious. People figured out this stuff decades ago when we all build our little projects with PHP and we always had to sanatize server-side (the days before the SPA and reactive websites). I do wonder if modern web devs are actually capable of thinking outside their training-wheel bubble sometimes.
It's a problem with people starting with React and not plain DOM manipulation
facts@@stoogel
I still make websites with plain HTML5, backend technology doesnt matter. but always have to sanitize user input, I don't see how this is different. You're right, it's like new dev's have never heard of this before. They probably would be open to SQL injection attacks if they didn't have training wheels with prepared statements etc.
They aren't. They absolutely aren't.
@@iWhacko Most probably don't even use SQL because they drank the NoSQL flavor aid. The hoops you have to jump through to perform what would be a simple task in SQL always amaze me.
It's not safe to use htmx if you can't trust the hypermedia content coming from the backend. But in this case, don't you have a bigger problem?
do you know what sanitizing is?
@@anthonydugarte i think he is saying, your server is already rektified and sending malware to all your visitors, but if your server is compromised, no client framework would help
It's like don't use databases because there's SQL injection, and the "proof of concept" is just some script where SQL is string concatenated with raw user input. No one would do that - you would use parameterized queries for that. Similarly if you render HTML on the server you would use a templating engine/library which most likely provides HTML escaping already (most of the times you have to specifically disable escaping like in Twig or Jinja2).
That would make sense if htmx was presented as an addition to SSR templating engines but if you go to their website it's presented as a frontend framework and even directly compared to react. If people go in expecting it to behave like react then they must be aware that they need to handle XSS vulnerabilities themselves.
Edit: Also "It's like don't use databases because there's SQL injection" is almost a valid argument only you replace database with raw-dogging your own database connector which is an argument people make and it's a good argument. Content sanitization be that for the purpose of preventing SQL injections or XSS attacks is difficult so we often make use of pre-existing tools that build on previous knowledge regarding these attacks. It's almost never a good idea to implement your own solutions when security is involved.
@@smallfox8623 I've always seen it mentioned as a tool to be used with frameworks like Django (without DRF) and thus with templating engines, might be a marketing issue on their front page then
@@smallfox8623 I have to agree with actualwafflesenjoyer. Even react call itself a "library". HTMX calling itself a frontend framework is meaningless. HTMX presents itself as a tool to render and update html server-side using https verbs. That's the tool. If you assume every "frontend framework" will have all the bells and whistles, including security, you are in bad luck
In my opinion, sanitization should always be implemented on the backend, regardless of whether or not the frontend is handling it. Generally, the backend is a much safer environment to perform these tasks, as it allows greater control over your code. Since anyone can manipulate things on the frontend and send them to the server, prioritizing backend sanitization ensures a higher level of security.
if you sanitize on the clients side you should do it on the data you receive from the backend and not / not exclusively on the data sent. however, it is still a better idea to sanitize on the backend for performance reasons imo
@@stellarwind932 why should i sanitize data received from the backend if i sanitize before sending on the frontend? I don't get the connection here.
In my job the data is validated and sanitized on the backend and additionally validated on the frontend for the UX reasons (imagine having bad connection and having to wait for validation each time you try to submit)
@@ElektrykFlaaj If you sanitize before sending you are still vulnerable to XXS attacks. It is a matter of opening the development tools and checking which post request is being made. Then you can just send an analogous request skipping the sanitization step. Basically, you cannot assume that any checks performed by the frontend will not be skipped by a user with programming skills. You can either sanitize the input sent by the server in the frontend or sanitize it in the backend (the most sensible choice), but you should not sanitize it in the frontend before sending it.
@@ElektrykFlaaj because I can open developer tools, see what endpoints you're hitting, and pass it whatever the fuck I want.
There is 3 things i can be sure about in this life.
1. We all die
2. Jeffrey epstein didn't kill himself
3. ThePrimeagen won't turn off alerts before recording a yt video on stream
4. You can have victory over sin
Man, my Professor for WebEng had to listen to so many people complain about how outdated his course was because he was focussing on the basics of HTML and jQuery, data sanitization, attack vectors etc.
This was not long ago and now I'm sitting here wondering how many of my class mates would re-x the OP... I get that not everyone goes to Uni, but man, you cant just skip the basics and then act indignant when a framework doesnt do it for you.
If you skip on security it will come to bite you. If it is no longer viable attack vector there is a reason for it and if you don't know what is the reason for it you might skip on it. And then you will very much know what the reason if for the rest of your life.
what in the ever loving fuck is a "re-x"?
@@terezip2213 people bending over to new twitter name, personally i will never stop using original name, "x" makes no sense in the sentence.
@@WoolieOGthanks for explaining. Man X was a stupid rebrand
The problem is, people have been trained for years to not worry about xss, by modern ui frameworks and simplified sever side requirements (they mostly have to handle json, which have strict syntax). You must have used jquery+mvc to have the previous experience with server side input sanitization.
Idk man, the first thing when I saw HTMX was "cool, I wonder what is the best way to sanitize it"
If you are working on the backend, and you're not looking on how to make your server secure when using a new tool, that is on you.
That's if you're a front end dev. If you're a backend dev, one of your first thoughts was probably sanitization. You should always sanitize on the backend, never trust the framework 100%.
@@Homiloko2 Yeah, true. But the channels hyping htmx are mostly the ones that usually talk about frontend, making it seem that htmx is a replacement to react, instead of a complete shift of the development to the backend. That is the problem. Well, was. We already are passing the initial hype, and people are clearing things up.
@@RonaldTetsuoMiura Well, it's always a matter from where you're coming from. In my circles it was more a "cool, we can easily add some interactivity to our mostly static backoffice apps without having to spend a bunch of extra time on frontend development", so basically just do the same thing we did before just add some `hx-****` on some elements and otherwise keep doing the same thing we did before.
HTML being extended to embrace the concepts of HTMX sans JS. Sounds like the web world my 2010 self wants to live in (was react a mistake?). The only requirement is to maintain the HTMX viewpoint of "don't care, just give me hypermedia".
"don't care, just give me hypermedia". Love it
Of course sanitize on the back end. That ensures that if someone tries to send things to your back end without just filling out your form, it'll still get sanitized. Don't trust the front end to do it right
wait
wait
wait
if i as the server send the client some javascript, i would expect them to execute it (on my authority/origin/whatever)
how is this not the default and expected behavior?
If you use any popular templating framework in the backend, you are almost completely safe from Reflected XSS
When's the last time you had a pentest done?
@@lavender0666 I know this is a generalization, (am a security researcher myself), but it’s not very useful to overcomplicate security things. The “issues” HTMX introduces can all be fixed by using a templating framework the way you are supposed to.
For correctness I added some more vagueness to my comment, but my point is that the risk these Twitter people are talking about is very small in practice
@@J0R1AN ah alright that's fair, thanks for the clarification
It's shocking to me that implicitly these devs who claim htmx is insecure are implicitly admitting they'd create security vulnerabilities in it without the guardrails in server -> client.
Meaning their servers are probably _pwned_ the moment they handle raw user input from clients.
Backend should never trust the frontend. Frontend should never trust the backend. What's between the chair and the machine should never trust the machine.
C-3PO has been saying it in every episode for the last 40+ years.
TJ, the guy with 0 experience of doing the web, what a presentation of TJ
I'm insecure, too, but that doesn't stop people from using me
Never trust input, regardless of where it comes from. Someone can easily bypass the front end sanitization by sending hand crafted requests. Don't trust the back end unconditionally because attackers could alter source code. I prefer sanitization on the receiving end. So, you would sanitize incoming data, not outgoing data. Back end sanitizes incoming requests from the front end; front end sanitizes requests coming from the back end.
That makes a lot of sense
@ryangrogan6839 - Best comment here !!!
The correct sentence is: "HTMX is the most dangerous thing in a while for dumb developers, in contrast to React HTMX doesn't pet you, you'll need to grow up"
"HTMX is the most dangerous thing in a while for 'React/etc developers', web developers have handled this for a while"
Frameworks are for people who don't like programming. The solution is to choose another career path.
I'm a front end dev and I'm not shook, I've always felt that way, why is JS required for so much, and HTML stopped getting better? In the beginning all the stuff that you would just *always* use JS for became HTML/CSS functionality. :hover for example. And web dev could have sooo much less complexity to it.
Validation belongs at the API layer. Your clients should never consume 3rd party APIs, but instead proxy them through a BFF API that handles sanitization for both incoming data (sql injection) and outgoing data (xss).
In case you just have a very simple use case. No need to worry about scaling issues, so just do it wherever it's convenient 🤷♂️
Hey, I mostly agree with your points but I think this fact would be beneficial for htmx users to know (possible that Nathan James's tweet was about this):
*XSS attacks may happen even if you sanitize user input html if you don't do the following.*
On top of html sanitization, htmx ADDITIONALLY requires sanitizing out hx properties in tags because htmx can run javascript with tags with those properties.
This is *not* to say that htmx is dangerous, but rather that you should take extra care when showing user input html.
I suspect this also applies to WebComponents as well, so I'm really glad I tried to understand the CSP section in htmx documentation.
This thing happens with "backend" devs that learn a web framework when they start out, like Laravel, and skip the whole "this is how the web works" part of the learning curve. When they step out of the frameworks it's sqli and xss galore.
That's why they should start with a secure framework like django!
HTMX is just AngularJS reincarnated lol
It's really just "XMLHttpRequest" with some training wheels. I love the shit out of it.
Dear Prime:
Thank you for enlightening me. Your videos help me to narrow the scope of what I need to learn next. You have ultimately saved me a lot of time by helping me to focus on the things that are important to know that allow me to build the stuff I will want to build in the future.
NEVER TRUST the FRONTEND, people can fake to be the frontend and send stuff you don't want. IT is always the backend the ensure valid input.
or you are done.
If you only sanitize the frontend, wouldn't you be vulnerable to people just disabling your js and then sending crap to your backend anyway?
I'm sure Little Bobby Drop Tables would disagree about backends sanitising inputs
Sanitization needs to happen right before generating the output format, when it's known what the output format is. Otherwise, if you pre-emptively sanitize everything as early as possible, you'll reinvent PHP's magic quotes. 🤢
When generating HTML, escape the data for HTML. When generating JSON, escape for JSON. When generating SQL, escape for SQL (using database engine and configuration dependent escape sequences). When generating CSV, escape for CSV (and hope the reader is configured to unescape using the same CSV variant).
If the data is pre-emptively escaped for HTML, but then one of the clients uses it to generate PostScript, you'll have XSS or garbled characters in your PostScript document, unless you take care to undo the HTML escaping before generating the PostScript.
Prefer generators which automatically handle the escaping. HTMX doesn't generate the HTML, so obviously it's not its responsibility to escape the HTML. The HTML templating library of your choice should handle it. You wouldn't generate HTML by string concatenation, the same as you wouldn't generate SQL by string concatenation, right? Otherwise you're back to writing PHP à la 1999.
As a complete and utter noob, I think the front end should sanitize things, because the front end is the one place where your code is locked, vaulted, firewalled, and generally completely immune to malicious intent unless any potential bad actor has the keys to the kingdom anyways.
. . . Wait, that's the back end? Shit.
glad you said the first sentence.
ITT people have no idea how XSS attacks happen
Gone back to day 0 of Prime forgetting to turn off the alarms
yeah HTMX is vulnerable to XSS
X: Skill
S: Issue
S:
The back end has to sanitize as well as the front end.
The back end will never accept any bad data, even if someone tries to directly use the API and mess with it.
The front end should sanitize what it sends and receives so that the rest of the functions work properly and nothing gets fucked where you don't expect it to.
If data is transfered, consider it dirty, always sanitize it and you're always safe.
In general, any outside input to any piece of software should be validated and/or sanitized. This is one of the most important concepts of secure software development.
A frontend bug is not the same thing as a compromised server. Sanitation isn't cheap and can add a ton of complexity/friction when it comes to maintenance. There's always going to be edge cases where something like "sanitizing in the frontend" makes sense, but it's completely unnecessary 99% of the time when it comes to standard webdev because most frontends should have as little responsibility as possible. Sanitizing in the backend is *always* a must.
Frontend sanitizing is good for UX, that's about it. Realisticly it's easy to bypass and manipulate. You can't trust the front-end sanitization (which you'll have to do in JS) is actually being applied before a request gets send to the backend. Heck try to frontend-sanitize my curl request to your backend :P
As a fake doctor, I was taught in fake medical school that you should never depend on the client to sanitize data. That's insane.
I love HTMX.. because I am still used to doing it that way from 15yrs ago... with a bit a of jquery back then.
But really I love that someone has made a minimal and canonical implementation for what you need in 95% of cases, and it's NON-INTRUSIVE. it's LOOSELY COUPLED. It doesn't say anything about what you must use on the front-end or the backend, or what you build system needs to look like (just don't have a build system!).
IMO it makes 95% of the world's JS obsolete. And that has to be a good thing!
great guest. does he stream anywhere?
This is tj devries. He’s on TH-cam.
First heard about HTMX in 2020, I was very close to adopt it on a Django project, before I decided to learn Vue because I found it way more flavorable than React and the advantage of employability. I do not regret my decision, but back then, I always praised how HTMX was so stupid simple and could one day replace React _et al._ in quite a few web applications; Especially simple sites. I can only assume that nowadays, it's even better.
Shocking! HTML documents and HTTP servers are all dangerous... because if you let users upload .html files inside the web root/asset directory... users can 0wn your site 😲 Did someone not get the memo 30-odd years ago and remained sheltered from basic reality until now?!
I don't get front end sanatizing wouldn't that make the backend vounerable for attacks?
Everything in this chat comes from how almost the entire industry pivoted into being "React", with people being specialists in just that alone. None of these conversations even begin if people truly understand the fundamentals of coding for the web.
This is not an insecure package problem, this is an ignorant developer problem.
There is actually a major advantage to sanitization in the frontend. You have access to the exact parser that is going to execute it. There have been a lot of xss attacks that exploited a difference between the implementation on the server and the client in some edge cases.
Any one who is serious about using XSS, won't be stopped with a frontent sanitization. You can quite easily bypass the frontend all together.
I think this is a great demonstration of Jonathan Blow's talk about how software is getting worse. Part of his point was that programmers are so far removed from what's really happening on the computer that they don't think in those terms any more. Nathan James is so far removed from having to actually think about what his network communication actually consists of that he freaks out when something makes him do it again.
Backend validation is must - if you only validate on client then I go visit your page and look at communications and willl call your server endpoints with compromized data.... okay... I will not - but trust me someone will ;-)
So validation can only safe server-only or server+client (just for faster UX maybe)
Since vue is so great for progressive enhancement by having components outside of full apps have a feeling HTMX + free flaoting vue components for those things that do need frontend interaction (say a markdown editor for a blog site, without server input from each keystroke which would be insane) will be the way of the future now we just need a good server implementation for common cases instead of everyone making their own
I like this idea
couldn't you use webcomponents for that? those seem like free floating components for drop-in interactivity without a framework
@@somenameidk5278 That is an option too if you prefer that option, but in the context of "I want a framework" vue makes MUCH more sense
We need a library of custom web components built with HTMX and Tailwindcss...then we can go home early and sleep like a baby.
Front-end 'security' lol!
Noob question, doesn't HTMX way of doing things mean you'll use a little more bandwidth compared to JSON ?
Wouldn't that mean HUUUGE difference in bandwidth on large websites?
Seems that the same people that like Tailwind like HTMX and don't both transfer way more data than needed? Isn't this like a step back?
Text compresses very well. We have a site serving around 10,000 requests per second of html and it comes in at about 150 mbps. The cost is a rounding error.
imo backend should sanitize since you could theoretically have multiple front ends, take netflix for example. Let the powerful beefy server do all the work, instead of writing sanitization for your android app, web interface, desktop app, console app, etc.
Well, that are basics of securing server-side application. First: don't let your server be overtaken by hackers (seems pretty obvious). Second: sanitize / validate every input coming from the client. You say, frontend can sanitize / validate it and backend should just trust it? Have you heard of F12 'hacking tool' that allows you to edit basically everything on client-side?
Have you heard about Server-Side Rendering att all? Php maybe? This new hot thing?
Some people are just so much in a bubble or detached from reality, lol.
I prefer Phoenix Frameworks Liveview implementation for this server powered reactive UI's concept. always feels far more tightly coupled to server. Helps when the ecosystem for both the underlying language and the web framework as well as the websocket powered reative UI share so much collaboration from the creators themselves, Elixir is doing this really well atm
The framework by design should prevent bad things from happening by default. For example, rails sanitize content going into erb by default.
Developers are humans, they always make mistakes.
Developers should not even need to know the intricacies of XSS, and everything should work fine.
Else bad things will happen as we see in PHP apps.
Also, scissors are dangerous because you might run with them while your eyes are closed
I am still trying to understand the issue. Isnt validation of data your responsibility ? Htmx is fine
Validation and sanitization needs to be performed on the back end in my opinion, Its the last gateway before your database, and even if the HTML was sanitized, you still need to sanitize against sql injection etc.
Of course no website should solely rely on front end sanitization. Anyone could simply write their own custom HTTP requests and bypass the frontend sanitization.
We are SO back to the jQuery golden age, bros.
There's still state on the client with htmx... its just not in js... its in html. A list of tweets displayed by htmx to the user is still state... that can become stale if the user sits there and reads them for 10 minutes before interacting with it.
Sanitize any form of input that the user has. ANYTHING they can mess with.
I am become react, the sanitizer of html
😂😂😂😂😂😂😂😂
I agree with TJ's idea. I'm wondering why this isn't reality yet...
How much do you post per day ?
His answer (probably) :
Yes
most clips are taken from his streams, and he streams quite frequently
I never thought front-end XSS protection in a browser is a thing, always sanitized at server-side in addition to some in-between comprehensive protection.
Will have to see if HTMX ends up just being flagged as a vulnerability in security vulnerability reports. And that's the end of it... It doesn't matter if security can be fixed. Once it makes it to the report, you're done...
the most crazy things in ef, is think there are any js framework that is secure against xss
it triggers me a little bit that they don't seem to think being able to execute js on a website isn't vulnerable. Alert(1) is just a demonstration
htmx is the logical endpoint of HATEOAS. The only thing that would make things even better is if CSS was always advanced enough to allow for 100% semantic markup and absolutely no markup that is only required for purely visual purposes. It is way closer than it used to be. But I still often find stuff I can't do without wrapper containers even with custom html5 tags and modern css.
To my mind we are getting closer every day to the web as Tim Berners-Lee originally envisioned it augmented with dynamic content. Especially since we are now in the evergreen browsers era of the internet, where you can pretty quickly transition to the bleeding edge in most deployment scenarios without worrying too much about compatibility.
I think TJ is right that this type of thing should eventually be just part of the normal W3C spec of what HTML should be able to do. I am confused by the fact that so many react devs are apparently fundamentally confused by how hypertext works.
That genius was able to hack himself, did Tom start a new career in frontend development?
backend should sanitize if its possible for client to run something (like sql injection sanitization), but if its just a string to store and then a string to read (like html/css/js/whatever you allow for users to format), frontend should sanitize because of browser differences
by the way, you are totally allowed to modify your frontend, and hack yourself with xss, but others will not be hacked because their frontends sanitize for xss still
@@CYXXYCIf you hack yourself, it shouldn't be "cross-site" scripting, right?
No? Backend should render HTML and escape all texts spliced into the template. Something that every template engine already does for you. Problem solved.
@@freesoftwareextremist8119 oh you do you. in my personal opinion templates are a mistake
@@CYXXYC And how do you like to generate your HTML?
having your frontend sanitise data before submission does not prevent XSS attacks, it just gives a false sense of security.
You can simply submit your own unsanitised data to the backend. I
n a modern JS webapp generally all the inner-workings of the backend business logic and models are implictly exposed through the API, so you have a Smorgasbord of options to you to exploit. If a dumb dev relies purely on FE protection they've exposed themselves to XSS attacks. Whereas the HTMX developer will realise much quicker that they've forgotten to protect their submitted data.
Hot take but if you need a framework to protect you from xss you probably aren’t that good of a Developer
If you need a framework period, you're not a good developer.
my issue is that Carson confuses html with hypermedia, hypermedia is having interactive non-linear content connected by links and this can be done without html, like info pages in linux or hypercard in macos or gopher pages or vim docs or orgmode or markdown or djvu etc. HTML is just a format of hypermedia and any format can be included as long as it is a node in the graph of hypermedia node would be content + links, and with JSON APIs people have made HATEOAS sites
that is a very specific, niche upsetness. communication is often through reduced "btw"s because it becomes annoying. prefacing everything you have to say to be the most technically precise is an increasingly annoying thing
its called htmx, its centered around html, its ok to call it hypermedia. it doesn't mean that something else "isn't" hyperemedia, its just not the focus.
@@ThePrimeTimeagenmy point was never that "something else is hypermedia as well" my point is HTML is not hypermedia. HTML is plain text that describes hypermedia, just like the word "apple" is not an apple (the fruit or the company)
precision is necessary when we do engineering or science or anything related to machines.
So this is the X from HTMX then? XSS? I see
Even if you inject XSS into the database, if the client uses a framework like Angular for example, the artack doesn't work. It doesn't do anything like innerHTML, parsing a string into HTML (which I consider a very bad practice). Even if you force an innerHTML, you have to DISABLE Angular sanitization for it to work on purpose..
17:00 wasn't that exactly the idea of XHTML2? (note the X at the beginning, not the end!)
Htmx+flask = newbies wet dream
Source:I'm a newbie
you still need to sanitize server-side, have people forgotten that Curl is a thing and i don't need your FE app at all to be making REST calls to your backend?
We make the web better by leaving it alone and not trying to fix things that arent broken
As computing evolves, hypertext protocol will most probably not😂
What DJ does?
and that is why is insecure because people have to do the job in the backend, that means all these poor souls who have been sacrificed to the altair of react.complexity have to learn a real backend framework
So HTMX doesn’t have a vulnerability, it’s just easier to write vulnerable code yourself.
Who the hell does not sanitize server side? Wtf?
Never trust the user.
this, yes, 100%
17:00 someone has watched Dylan Beattie's "The Web That Never Was"
Regarding the recommandations of sanitizing HTML in the frontend rather than the backend, I think this comes from concerns regarding how malformed html is parsed differently in each browser.
There is this great video of liveoverflow explaining that : th-cam.com/video/lG7U3fuNw3A/w-d-xo.html
But basically when a browser receive malformed html, it will always try to correct it (by adding missing closing tag for exemple). But there is no global spec regarding this corrections which means every browser will have it own strategy to correct the html input.
The issue becomes that trying to sanitize html on the backend will mean you will need to know the specific implémentation of each browser to make sure what is send is not vulnerable to xss attack.
Where as if you validate the html on the browser, you won’t have to deal with this specific because you can work with the same html parser that will evaluate yout html input.
Obviously my explaination is over simplified but the liveoverflow video above explain it really well imo
That sounds interesting, thank you for the link
You are not supposed to sanatize HTML like this. You escape it. Simple, problem solved. You can do this on the server. And in fact, every templating library known to man does that. And if you use HTMX you probably use one and don't concatenate HTML strings on the backend.
@@freesoftwareextremist8119 Well that only works if you're trying to fully sanitize user input (which is of course the most common use case).
But sometimes you want to allow some html markup to be inputed by the user (for exemple in a blog app where a user can create a post with enriched content and formatting). In this case, you can't just escape the content since you need to eval it on the front-end
It's in this case where sanitizing on the server-side can lead to vulnerability. A malformed HTML could seem harmless at first but be evil once it's parsed ny the browser
Had exactly this video from liveoverflow in mind when scrolling through the comments.
Every browser trying to correct malformed html in its own way is a big problem imo.
HTML parsing is fully defined by the standard though (google html spec, under the parsing section, I can't put the link in this comment). A proper sanitizing library does implement a full spec-compliant HTML parser. But of course, although rare, there may be some bugs.
Side note: The reason you should always put at the top of your document is because it puts the browser in "standards mode" as opposed to "quirks mode", which IIRC also influences the way the browser parses your document
I thought it was pretty common for web servers to send html to the client lol
yah know what pilots do every time before starting the engine? they go through a rigorous checklist. make a checklist, be sure that 'turn off notifications' is in it, and you're good, dude.
My HTML parser blocks script, style, link, embed, and tags and anything that has *src="javascript: ..."* or *href="javascript: ..."* attributes. And that's on top of all of the usual input sanitization and SQL quoting.
Actually PHP do that since 1994
Im doing this HTMX thing before I learned to use Angular and React. Im doing this using PHP hahaha.
12:45 Isn't server-side-only state a problem for complex websites (esp. applications)? You want client-side state, you don't want all interactivity that goes beyond that in the HTML controls themselves to require a round trip. And 15:45 returning HTML on the client side sounds cumbersome. Besides, declarative UIs are a good thing in my opinion.
someone should make a "every Prime video ever": I FORGOT TO TURN OFF THE ALERT THANK YOU SO MUCH