Vue.js

2019-05-04

Source

Edit

History

Security

카탈로그

1. Reporting Vulnerabilities
2. What Vue Does to Protect You
1. 2.1. HTML content
2. 2.2. Attribute bindings
3. Potential Dangers
1. 3.1. Injecting HTML
2. 3.2. Injecting JavaScript
4. Best Practices
5. Backend Coordination
6. Server-Side Rendering (SSR)

Reporting Vulnerabilities

When a vulnerability is reported, it immediately becomes our top concern, with a full-time contributor dropping everything to work on it. To report a vulnerability, please email vuejs.org@gmail.com.

While the discovery of new vulnerabilities is rare, we also recommend always using the latest versions of Vue and its official companion libraries to ensure your application remains as secure as possible.

What Vue Does to Protect You

HTML content

Whether using templates or render functions, content is automatically escaped. That means in this template:

1	<h1>{{ userProvidedString }}</h1>

if userProvidedString contained:

1	'<script>alert("hi")</script>'

then it would be escaped to the following HTML:

1	<script>alert("hi")</script>

thus preventing the script injection. This escaping is done using native browser APIs, like textContent, so a vulnerability can only exist if the browser itself is vulnerable.

Attribute bindings

Similarly, dynamic attribute bindings are also automatically escaped. That means in this template:

1
2
3

<h1 v-bind:title="userProvidedString">
  hello
</h1>

if userProvidedString contained:

1	'" onclick="alert(\'hi\')'

then it would be escaped to the following HTML:

1	" onclick="alert('hi')

thus preventing the close of the title attribute to inject new, arbitrary HTML. This escaping is done using native browser APIs, like setAtttribute, so a vulnerability can only exist if the browser itself is vulnerable.

Potential Dangers

In any web application, allowing unsanitized, user-provided content to be executed as HTML, CSS, or JavaScript is potentially dangerous, so should be avoided wherever possible. There are times when some risk be acceptable though.

For example, services like CodePen and JSFiddle allow user-provided content to be executed, but it’s in a context where this is expected and sandboxed to some extent inside iframes. In the cases when an important feature inherently requires some level of vulnerability, it’s up to your team to weigh the importance of the feature against the worst-case scenarios the vulnerability enables.

Injecting HTML

As you learned earlier, Vue automatically escapes HTML content, preventing you from accidentally injecting executable HTML into your application. However, in cases where you know the HTML is safe, you can explicitly render HTML content:

Using a template:
1
<div v-html="userProvidedHtml"></div>

Using a render function:

h('div', {
  domProps: {
    innerHTML: this.userProvidedHtml
  }
})

Using a render function with JSX:

1	<div domPropsInnerHTML={this.userProvidedHtml}></div>

Note that user-provided HTML can never be considered 100% safe unless it's in a sandboxed iframe or in a part of the app where only the user who wrote that HTML can ever be exposed to it. Additionally, allowing users to write their own Vue templates brings similar dangers.

### Injecting URLs

In a URL like this:

1
2
3

<a v-bind:href="userProvidedUrl">
  click me
</a>

There’s a potential security issue if the URL has not been “sanitized” to prevent JavaScript execution using javascript:. There are libraries such as sanitize-url to help with this, but note:

If you're ever doing URL sanitization on the frontend, you already have a security issue. User-provided URLs should always be sanitized by your backend before even being saved to a database. Then the problem is avoided for _every_ client connecting to your API, including native mobile apps. Also note that even with sanitized URLs, Vue cannot help you guarantee that they lead to safe destinations.

### Injecting Styles

Looking at this example:

<a
  v-bind:href="sanitizedUrl"
  v-bind:style="userProvidedStyles"
>
  click me
</a>

let’s assume that sanitizedUrl has been sanitized, so that it’s definitely a real URL and not JavaScript. With the userProvidedStyles, malicious users could still provide CSS to “click jack”, e.g. styling the link into a transparent box over the “Log in” button. Then if https://user-controlled-website.com/ is built to resemble the login page of your application, they might have just captured a user’s real login information.

You may be able to imagine how allowing user-provided content for a <style> element would create an even greater vulnerability, giving that user full control over how to style the entire page. That’s why prevents rendering of style tags inside templates, such as:

1	<style>{{ userProvidedStyles }}</style>

To keep your users fully safe from click jacking, we recommend only allowing full control over CSS inside a sandboxed iframe. Alternatively, when providing user control through a style binding, we recommend using its object syntax and only allowing users to provide values for specific properties it’s safe for them to control, like this:

<a
  v-bind:href="sanitizedUrl"
  v-bind:style="{
    color: userProvidedColor,
    background: userProvidedBackground
  }"
>
  click me
</a>

Injecting JavaScript

We strongly discourage ever rendering a <script> element with Vue, since templates and render functions should never have side effects. However, this isn’t the only way to include strings that would be evaluated as JavaScript at runtime.

Every HTML element has attributes with values accepting strings of JavaScript, such as onclick, onfocus, and onmouseenter. Binding user-provided JavaScript to any of these event attributes is a potential security risk, so should be avoided.

Note that user-provided JavaScript can never be considered 100% safe unless it's in a sandboxed iframe or in a part of the app where only the user who wrote that JavaScript can ever be exposed to it.

Sometimes we receive vulnerability reports on how it's possible to do cross-site scripting (XSS) in Vue templates. In general, we do not consider such cases to be actual vulnerabilities, because there's no practical way to protect developers from the two scenarios that would allow XSS:

The developer is explicitly asking Vue to render user-provided, unsanitized content as Vue templates. This is inherently unsafe and there’s no way for Vue to know the origin.
The developer is mounting Vue to an entire HTML page which happens to contain server-rendered and user-provided content. This is fundamentally the same problem as #1, but sometimes devs may do it without realizing. This can lead to possible vulnerabilities where the attacker provides HTML which is safe as plain HTML but unsafe as a Vue template. The best practice is to never mount Vue on nodes that may contain server-rendered and user-provided content.

Best Practices

The general rule is that if you allow unsanitized, user-provided content to be executed (as either HTML, JavaScript, or even CSS), you might be opening yourself up to attacks. This advice actually holds true whether using Vue, another framework, or even no framework.

Beyond the recommendations made above for Potential Dangers, we also recommend familiarizing yourself with these resources:

Then use what you learn to also review the source code of your dependencies for potentially dangerous patterns, if any of them include 3rd-party components or otherwise influence what’s rendered to the DOM.

Backend Coordination

HTTP security vulnerabilities, such as cross-site request forgery (CSRF/XSRF) and cross-site script inclusion (XSSI), are primarily addressed on the backend, so aren’t a concern of Vue’s. However, it’s still a good idea to communicate with your backend team to learn how to best interact with their API, e.g. by submitting CSRF tokens with form submissions.

Server-Side Rendering (SSR)

There are some additional security concerns when using SSR, so make sure to follow the best practices outlined throughout our SSR documentation to avoid vulnerabilities.