We live in the age of frameworks, not languages. This implicates that programmers should be able to worry less about many aspects of development, including security. The majority of current backend frameworks implement security modules, which are being tested by external, specialized companies and large societies. Therefore, declining security awareness could be apparent, for example between young programmers, who take more responsibility for the products, especially in terms of freelancing.
Login form on page renders loginName parameter send within GET request in login name input. Value is not processed neither by server or client-side of the application. By requesting:
http://localhost:8080/login?name=<script>alert(document.cookies)</script> code is being executed and data is exposed
This is an example of a reflected XSS attack, where scripts are being injected through specially prepared URL address submitted to the victim and reflected by the server response. Other known popular forms of attacks are as follows:
– Stored XSS performed with injected data stored on the server-side, usually by forms available in the application. The client application renders code that is stored, for example, in a database.
– DOM XSS performs an XSS attack with no use of the server-side. In the further part of article, we will focus on this form of attack.
Current vulnerabilities in React and Vue libraries
For the current React/Vue versions, two major problems had been detected and not yet officially fixed. The first vulnerability has the same nature for every framework and is related to methods allowing raw HTML rendering within templates: v-html and dangerouslySetInnerHTML, respectively, for Vue and React. Each documentation  informs readers that unwise usage may expose users to XSS attack. If no other options allow for resolving the problem, ensure that the data is filtered and escaped. Although they are dangerous, you should not expect those methods to be fixed. Use them at your own risk.
If updating to the latest versions is not possible, make sure that old issues don’t cause problems for you by ensuring that your code is not exposed for:
– child node injection – React, usage of React.createElement 
– server-side rendering – React/Vue  
– CSS injection 
Here, using linters with proper rules set may be helpful in finding such vulnerable points. There are also plenty of open or commercial code analyzers that may help you detect security gaps in developed code. OWASP has proposed a list, available here:
No matter which library/framework is chosen, we still have to remember basic principles related to front-end development. First, always ensure that the external code you inject comes from a trusted source. Audit your dependencies, and choose them wisely. Some can contain serious vulnerabilities, exposing your code even if everything is fine with the code itself. You can read more about dependencies security here:
So… should you still be concerned?
Yes – and I strongly encourage everyone to never trust external libraries or yourself in terms of security. No matter how safe you expect your software to be, always make an effort to test it as much as possible in terms of common attack forms .