Posted on Oct 21 JavaScript is one of the most widely used languages in the world.It is not only the basic programming language that runs on the web, but also appears to have high demand as a server-side programming language since the advent of Nodejs.However, how well do programs made with JavaScript, especially web services, protect their security?We will learn about the basic security policies of JavaScript that must be observed regardless of programming skills.XSS, or cross-site scripting, is a type of attack that injects malicious code into a web page. It can be classified into two main types reflected and stored.Web browsers have a number of security policies in place, including one that invalidates Script blocks inserted by the browser. This means that even if someone were to manipulate something like HTMLElement.innerHTML to inject a script block into a page, the script would not execute.So what's the problem? The problem occurs when malicious scripts are downloaded from the server.Reflected XSS is a vulnerability that occurs when user-supplied parameters are inserted into a page without validation.For example, when showing search results based on the value of the query parameter q, if the value of q is inserted into the search bar directly, it can be used to create a URL that executes malicious scripts to a domain such as Dev.to.One way to address this is to escape tag characters to make them strings.Stored XSS is a type of attack that works on the same principle as reflected XSS, but it stores malicious scripts on the server's database using functions such as a bulletin board.It may seem that it can be dealt with in the same way as reflected XSS, but the thing to consider here is functions such as WYSIWYG.To support WYSIWYG, only the function that executes scripts without invalidating HTML should be filtered.The filtering targets are as follows.Of course, script tags should be filtered, and href attributes with javascript or event handlers starting with on should also be filtered, even though they are executed when the user clicks.Here, it is important to note that filtering can be bypassed using \ , or malicious scripts can be executed without clicking using onmousemove and some styles.If you use the URL sent by the user without validation in the redirection, it can be used to create URLs such as dev.to?redirectUrl=attacker.site, similar to reflected XSS.SQL injection is a vulnerability that allows an attacker to escape the string range using comments and manipulate SQL freely if the user's input is inserted into the query directly.It is a vulnerability that can lead to fatal damage, such as the theft of all personal information on the server or the deletion of data, but if you use the Prepared Statement function, you can treat all user input as simple strings, so no problems occur.Web apps are vulnerable to attacks because they allow users to freely execute JavaScript through features like the console, and attackers can intercept communications, send manipulated requests, or receive manipulated responses.All validation logic should be handled on the server.Client-side validation is almost useless except for reducing server traffic due to bad requests.I have listed various security vulnerabilities and their solutions, but in fact, all of these methods are based on not trusting the user's request.This also includes business logic processing.Even when processing basic CRUD, use the data from the database rather than the user's input values.Thank you.Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Jeeanny - Oct 18 Adeleye Ayodeji - Oct 5 Xing Wang - Oct 9 Thiago Bertuzzi 👨🏻‍💻 - Oct 5 Once suspended, artxe2 will not be able to comment or publish posts until their suspension is removed. Once unsuspended, artxe2 will be able to comment and publish posts again. Once unpublished, all posts by artxe2 will become hidden and only accessible to themselves. If artxe2 is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Yeom suyun. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag artxe2: artxe2 consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging artxe2 will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.