Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

JavaScript jQuery Basics Introducing jQuery Blog Previewer: Getting Values from Form Fields

Mahfuzur Rahman
Mahfuzur Rahman
3,204 Points

.text(title) but .html(content)

why are we using $('#blogContentPreview').html(content) instead of $('#blogContentPreview').text(content)

4 Answers

Steven Parker
Steven Parker
229,644 Points

The "html" method allows the content to contain markup tags (such as the "<strong>" shown in the example), but the "text" method does not. If you were loading the content with "text", then the "<strong>" tag would show as-is instead of causing the area it encloses to be emphasized.

If you wanted to allow markup to be used in the title, you could substitute the "html" method there also.

A little experimentation might be worth more than any explanation!

Mahfuzur Rahman
Mahfuzur Rahman
3,204 Points

Thanks a lot! Actually I tried both, but without the <strong> and got the same output and hence I asked for help :)

Kaitlyn Dodds
Kaitlyn Dodds
32,545 Points

It's worth noting that the use of html() to display html encoded content exposes a security vulnerability.

Try typing:

<script>alert('You've been hacked!')</script>

into the content input, then pressing 'Preview'.

You should see the alert pop up on screen. This occurs because we are blindly trusting the user data, and not attempting to sanitize the content they provide. This vulnerability could expose our site to attacks such as Cross-Site Scripting that have much bigger consequences than just an annoying alert box popping up.

Steven Parker
Steven Parker
229,644 Points

This is more of a performance and error prevention concern than one of security, since any injected script code is executing on the user's own machine.

Your point is worth noting, and a reasonable effort should be made to protect novice users against accidents. But deliberate attacks are not a concern.

Steven Parker
Steven Parker
229,644 Points

As I said, that doesn't apply here because the input data goes directly onto the page in the user's own browser. XSS concerns only occur with data transmitted to a server (and then mishandled there).

In this particular scenario, a malicious user can only "attack" his own machine. :wink:

Kaitlyn Dodds
Kaitlyn Dodds
32,545 Points

I think you misunderstood.

Yes, in this exact scenario, this isn't a big risk because the application does not have a backend. The data is not at risk of being transmitted to a database or server somewhere.

However, if html() were used in an application with a backend, it would be exposing a huge vulnerability. One way an hacker might attempt to judge a site's vulnerabilities would be to run the exact same script I provided above in an HTML form input. The fact that the JavaScript is executed in the browser tells an attacker that the site could be compromised using Stored XSS.

I was merely attempting to point out that every developer, even beginner developers, should know that reflecting user data in the browser without performing any sanitization is dangerous. Security vulnerabilities such as this one are rarely mentioned to beginner developers, and often ignored by mid-level and senior developers.

Plus, it's fun to learn how to break your own site!

Steven Parker
Steven Parker
229,644 Points

I am quite sure I understood exactly.

And using the html() function isn't automatically a vulnerability even on the backend, but it could be in some situations if appropriate precautions are not taken.

I agree that every developer should be aware that reflecting user data in the browser may cause unintended results, but nothing "dangerous" or that could be considered a security vulnerability. The kinds of vulnerability you are talking about are not concerns for beginner developers. Those concerns apply to advanced developers of server applications and are well beyond the scope of this exercise, and for that matter, this entire course.

I just wanted to be sure that any beginners understand that nothing they do in this course can create any reasons to be concerned about causing any dangers or vulnerabilities.

Happy coding, everyone!