XSS Explained - What Is Cross Site Scripting - Build Expense Tracker App With PHP 8

[@Armando-px8hi]

Great Lesson, very useful for me, I am a student for cybersecurity and this was more than kust a lesson for me.Thank you Gio for covering this topics.

[@ProgramWithGio]

Glad it was helpful, thank you

[@hansschuijff]

Clear explanation and mostly a reminder with examples to properly escape output. Thanks for the lesson and the great OWASP resource.

[@ProgramWithGio]

You're welcome & thank you 🙌

[@omaryahia]

you are amazing man🙂never fail to amaze me thank you Gio for these amazing excellent lessons

[@ProgramWithGio]

Thank you

[@ismaelkhangane513]

It's really helpful to my self-learning! Thank you a lot

[@ProgramWithGio]

Happy to hear, you're welcome 🙌

[@RicardoVargasM]

Amazing video, congrats.

[@ProgramWithGio]

Thanks a lot!

[@Zubbee]

Great work Gio. I'll dig in

[@ProgramWithGio]

Thank you

[@behnooshmoshtagh382]

Thank you Gio!

[@ProgramWithGio]

You're welcome 💙

[@lautarolopez5372]

Great tutorials Gio!! Keep going!

[@ProgramWithGio]

Thank you 🙌

[@levani7851]

Fantastic as always

[@ProgramWithGio]

Thanks 🙏

[@Zubbee]

Thank you so much Gio for this lesson. Always wondered how some of these things were done. I'll do my best to do the OSWAP reading you highly recommended for us. I have a question I didn't in the earlier lessons. is it usually typical to first build components of an application and then refactor? or do ppl try to build the application with best code layout(not sure what word to use) so that you don't necessarily need to refactor again afterwards. in order words, should I aim at writing beautiful code from the get go? Or is is a usual Devs practice to write functional code first and then earmark another time for refactoring? Thanks again Gio

[@ProgramWithGio]

It's ok to write ugly code first & then refactor. My usual goal is to get it working regardless of how code looks. Then if it looks ugly I refactor it. Sometimes it doesn't look ugly, sometimes it does. That being said, I don't take too long to refactor because then it will never be done and you would just be building on more tech debt. I refactor it mostly on the same day, so I write & get it to work first & then right away refactor it.

[@Zubbee]

@@ProgramWithGio Okay great Gio. The way you described it being done in the same day makes a lot of sense. And then not accumulating tech debt (I like that phrase lol.) Seems like a pretty good idea.

[@asmadev8812]

hi Gio, thank you for this wonderful content, can you share with us a stream course ?

[@ProgramWithGio]

Hello, what do you mean by a "stream course"?

[@ნოდარდავითულიანი]

You guys should know that Gio is from Georgia🇬🇪🇬🇪🇬🇪

[@ProgramWithGio]

😁 🇬🇪🇬🇪

[@muhammadafnan_8819]

Sir plz make video on PHP PDO complete e-commerce project

[@ProgramWithGio]

Thanks for the suggestion 🙌

[@guy4722]

WOОORKING!!!! OMG!!!

[@ProgramWithGio]

Nice

[@benderbg]

Escape before job escapes you 🤣

[@ProgramWithGio]

Good way to look at it 😄

[@Octavus5]

Sanitize fields that need to be sanitized before saving into your DB. Sanitize fields that need to be sanitized when retrieving data from your DB. (This can be automated easily) Then the data you work with at the html level is always as it should be and there are no unexpected dangers. I don't think that you should ever leave it up to the HTML person to sanitize data. They should only think about displaying data. Personally, I don't understand the brouhaha about XSS. It's a simple problem to fix and every programmer should know how to do it without relying on 3rd party libraries. Or am I missing something here?

[@ProgramWithGio]

Generally I agree but you should save data in database table as is, as I stated in video it can cause bad user experience if you start converting HTML entities on save or removing HTML elements, a long text entered by user in a note field can contain special characters that are not harmful but you sanitizing and removing or converting them will hurt the UX when displaying that data not to even mention double escape. So rule of thumb is escape on output and HTML person or the one working on front-end should know that, and in backend you sanitize what you need but try to save the original text as is in the database table. Maybe you misunderstood, I don't mean to pass raw text in queries, of course you would still use prepared statements which protects you from SQL injection, I mean saving text safely in the database in it's raw form.

[@ProgramWithGio]

Also not sure what you mean by 3rd party libraries? We are not using any third party library, we are using Twig templating engine which is jus that a templating engine and provides protection. Even if you use plain PHP templates you still need to escape it manually otherwise you are vulnerable to XSS whether you sanitize data in backend on save or not.

[@Octavus5]

@@ProgramWithGio Hey Gio, really like your series. I don't disagree with really anything you've said. As I stated, sanitize what you NEED to sanitize, ie, what you ShOULD sanitize BEFORE it goes into the DB and when you RETRIEVE it from the DB. As the developer, you should know what they are; what fields; what sorts of data. Obviously, if you have comments data that allows for html, you don't want to completely sanitize that. You may want to allow for some css styling, but remove script tags. On the other hand, I think it's bad practice to let the HTML guy work with dangerous data and give him the power/opportunity to make bad mistakes. Anything that should be sanitized should already be sanitized before he gets his hands on it at the presentation/html level, in my view. Whatever data he works with should be harmless and innocuous and pre-sanitized. Twig is not native to PHP, so it is a kind of 3rd party library? External templating engines may be a good choice, but ultimately, optional. Personally, it doesn't seem to be a good idea to rely on templating engines to protect you against XSS attacks. All data should already be sanitized by the time it is handed over to the presentation layer. Enjoy your videos, Gio!

[@ProgramWithGio]

@@Octavus5 yea for sure, sanitize what you need to sanitize but I think you are misunderstanding something. Twig has nothing to do here, even if it's regular PHP you have to escape all output regardless if it's safe or not. Same way frontend can't rely on backend to have everything sanitized. All output should always be escaped on display, regular PHP that's done via htmlspecialchars function, in js context it's done via json_encode and so on. XSS is very dangerous and can't be taken lightly, it's not something only backend can take care of, person working on front-end should be well aware of what XSS is and how to properly escape it. Data may not be coming from database, it may be coming from API in which case you can't guarantee it to be "safe" and sanitized, so it should always be escaped. Templating engines just make it easier, we just happen to be using Twig in this series, if we weren't then we would be using htmlspecialchars to escape on display. I almost never apply htmlspecialchars on backend on save because that is worse in many cases where it opens up for double escape problems. Thank you btw 💙💙

[@ProgramWithGio]

Maybe the confusion is with wording "sanitize" vs "escape". Sanitize/filter input before going to database I agree, but escape on output. Here is one article where you can read more about it, I do disagree with couple of his points but is still worth a read: benhoyt.com/writings/dont-sanitize-do-escape/ And discussion on Reddit if you want to see what others think about it: www.reddit.com/r/PHP/comments/s32zcu/dont_try_to_sanitize_input_escape_output/hsifnhk?context=3

[@FGj-xj7rd]

Lmao. The thumbnail.

[@ProgramWithGio]

😂