How we bundle our code for development and production

Bundling with webpack and Parcel

Modern web applications are typically written with a modular pattern. This involves keeping our JavaScript in separate files and folders based on functionality. If we want to make use of our JavaScript code, not only do we have to add each file to the html, but also make sure each file is added in correct order of dependency. Or do we?

Bundling JavaScript

The problem presented above is a JavaScript bundler's main task to solve. In essence, any bundler starts with a given entry file. The dependencies of the entry file are traversed and all visited files are added to the same file, known as the bundle. The bundle, containing all of the necessary code, is the output of the bundler, and the only file the html needs to reference.

In this post we will take a brief look at two popular bundlers, webpack and Parcel, and how they bundle our code. Additionally, we will also explore how they further improve our daily life when building web applications.

These two JavaScript files will be used to show how:

A simple webpack example

Let us see how we can make webpack build our bundle. First of all, initialize a npm project and install webpack.

Now we only have to specify the entry file, which we will put in a config file.

For an easy way to run webpack, add it to the npm scripts in ./package.json

Finally run the npm script to bundle the files.

The config file will automatically be detected. By default webpack will place the processed bundle in ./dist/main.js. Inside the bundle we will find the contents of both index.js and santa.js in addition to some extra code inserted by webpack.

Now let's see if the code actually does anything. We will create an html file which references our bundled code and host it locally with a development server. Earlier this had to be done by hosting a local server, for instance with express. This is all part of the past now, since webpack have created a dev server for us. It is called webpack-dev-server and needs just a couple lines of configuration. Start by creating ./index.html

Install webpack-dev-server from npm.

Next, we will extend ./webpack.config.js with a bit more configuration for the dev server.

We feed the dev server with two variables. contentBase specifies where in the filesystem our files will be served from, ./ is the location of index.html. Meanwhile publicPath sets the location of where the dev server will host the bundle. Since index.html looks for the bundle in ./dist/bundle.js, we use /dist as the value.

As we did with the building of a bundle, we will also run the dev server with a npm script. Add the following script to ./package.json:

In addition to adding another npm script, we have also specified mode in our scripts. It tells webpack to optimize for either a production or development environment. Now we can use start to run a local development server, and build to create a bundle optimized for a production environment. By starting the dev server, we can visit http://localhost:8080/ and receive a nice and warm greeting from our browser.

A simple Parcel example

Older webpack setups are known to be large and complex, but with webpack 4 and webpack-dev-server, setup is far more friendly. However, when it comes to simplicity, Parcel takes it to a whole other level. Create a package.json and install Parcel globally.

All we need now, is an html file to feed Parcel as the entry point.

Run Parcel with index.html. A dev server will automatically start, so go ahead and visit http://localhost:1234 for another greeting.

If we want to bundle our code for production, Parcel has a production mode. It will optimize the bundle, just like mode=production does for webpack, and output a file instead of starting the dev server. Run the following command, and feed it ./index.js instead of ./index.html.

Which is best?

Although the two examples above show some differences between webpack and Parcel, a bundler impacts your project in a lot of other ways. For instance, Parcel claims to use 50 percent less time than webpack to build a project containing 1700 modules. Parcel is also undoubtedly more beginner friendly, giving a lot of features, like code splitting and hot module replacement, with no configuration. That being said, we have to appreciate how incredibly configurable webpack is. It allows us to tailor webpack to the specific needs of any project. It also lets developers extends its core features with custom plugins and loaders.

Bundling with webpack and Parcel

Do you want to try more hands on security testing, but you're not quite sure where to begin? Keep on reading!

OWASP ZAP (Zed Attack Proxy) is a free security tool created and maintained by the OWASP foundation. It is available for both Windows, Linux and macOS. ZAP offers a variety of functionality: It has several scanners that can crawl your webpage and detect possible vulnerabilities, it has fuzzers that help you generate and send illegal requests, and a whole lot more. But the most beloved functionality is probably the man-in-the-middle proxy. A proxy is the most useful tool in any security tester's toolbox, as a proxy allows you to look at all traffic between the web server and your browser. You can even pause, resend or change requests! Let's have a closer look.

Getting started

First, you must download and install ZAP. When you've got ZAP up and running, it is time to configure the proxy. One of the good things about ZAP is the user guide, and you can find thorough instructions for how to configure your favorite browser to use ZAP as a proxy here. If you use macOS I recommend that you do not use Chrome for this, because Chrome on macOS can not override the system proxy settings. If you change the system proxy settings to use ZAP as a proxy it will work with Chrome, but then ZAP will record all traffic to and from your machine, not just from one particular browser.

HTTPS

If the website you want to explore uses HTTPS (as it should), you will have to add a certificate to ZAP, and to trust this certificate in your web browser according to this guide. By doing this the web server will have a secure connection over HTTPS that is terminated by the ZAP proxy, and then ZAP will set up a new HTTPS connection between its proxy and your browser. This way you will be able to see the HTTPS traffic in plain text in ZAP.

Using the proxy

If you have configured your browser to use ZAP as a proxy and set up the ZAP certificate correctly, you should start seeing requests and responses in ZAP when you access some webpage. At the bottom you will see a chronological view of all requests including response codes, HTTP method, response time and size, and possible vulnerabilities (like cookies without HttpOnly flag or missing headers). ZAP will also create a map of the website under "Site". You can gather a lot of information just by monitoring the traffic. If you right-click on a request, you can choose to resend it, and you can edit it first if you want to.

Fuzzing

Let's say you are looking at a login page and you have a list of userids, and you want to find out if any of them are valid. It is time consuming to try them all, and besides, you don't have the password. What you could try is to use a fuzzer. If you capture the login message with your proxy, you can right-click on it, choose "Attack" and "Fuzz". Now you can choose the username as the parameter that should be changed, add your list of potential userids, and start fuzzing! Pay attention to the response times. Does any of the messages have significantly longer response times than the rest? Chances are that this is a valid user id. This can happen if the server rejects the login request immediately if the user does not exist, and if the user id is valid, it may take some extra time checking if the password is correct. This depends on what kind of password storage is being used, but with for instance bcrypt this can be a problem. Check out this presentation from OWASP Norway Day 2018 by Chris Dale about blind exploits for a live demonstration (he uses BurpSuite as his proxy tool, but you can do this in ZAP as well).

Don't try this at home!

It is important to remember that security testing web applications without permission is illegal. If you want to try these techniques in a safe environment you should take a look at OWASP JuiceShop. This is a simple web application with several vulnerabilities that you can run as a Docker container on your own machine. Some of the vulnerabilities are easy to find and exploit, others can be quite challenging. Happy hacking!

OWASP ZAP

Do you need to create a complex, yet reusable piece of UI? What's the best approach?

When I work on large applications, I often stumble across usecases where a simple component just isn't enough. These pieces of UI tend to be the ones that are reusable, flexible to fit a ton of usecases, and end up with a multiple-digit number of properties.

My favorite example of this kind of component is a card component. It can contain images, text, titles, lists, icons - you name it!

Here's an example of a typical, flexible component that's hard to use:

Tons of props, and it doesn't scale too well. What can we do?

Use children

The first enhancement we can do, is to place the most dominant piece of the content in the children prop - so that we at least feel like we're encapsulating our content in some sort of wrapper.

An added bonus is that using JSX feels more intuitive, too!

This, however, isn't enough. We still lack the flexibility we need to get rid of the rest of our pesky props! Time to do something drastic.

Creating sub-components

A typical approach when you find youself in such a situation, is to create what I call "sub-components". These components don't make much sense on their own, but they make up the individual parts of a larger component.

Our Card component, for instance, could be implemented like this:

If we just disclosed these sub-components somehow, and just let the consumer decide which order they should come in (and what props they should receive), we would be more flexible than a bungee cord.

Our component could then be used like this:

That's pretty easy to arrange a ton of ways, right?

How to make these sub-components available to the consumer?

So we now have a main component, and a few sub-components. How do we expose our API to the consumers? The way I see it, we have 4 alternatives

Alternative 1: Default + named exports

Our first alternative is to expose the main component as the default export, and any sub-components as named exports. You'd use them like this:

This works fine, but there's a few downsides too. You have to remember that there's both default and named exports, and you (most likely) need to prefix every component with the main component's name, in order not to litter the file-global namespace with imports. Still, it works just fine!

Alternative 2: Totally separate components

Keeping the sub-components as totally separate components might also seem like a good idea, but beware of other people using these components outside of their intended context too. There's little to no connection between your main and sub-components this way. Also - you'll get a ton of import lines!

Alternative 3: Default export + components as static props

A pretty popular way to solve this is by only exporting the main component, and then exposing any sub-components as static properties on it. You use it like this:

This is the way I've been doing this for a while. Yep, you still need to remember that the properties are there (just like alternative 1), but static code analysis tools can help out. In addition, you don't have to think about littering the global namespace with imports!

Alternative 4: Render props

A last alternative, and my favorite right now, is using the render props pattern to expose the available sub-components. The usage would look like this:

This alternative has two very distinct upsides.

Firstly, we can skip the prefix and namespacing, since the sub-components only are available in the scope of the children function.

Secondly, we can make our components smarter! Based on the different props passed to the main component, we can expose different sub-components too - in addition to any extra flags or functionality we want.

The only downside I can think of is the syntax itself - if you're bothered by that kind of thing, of course 😉

Go split up your components!

No matter what you decide, I hope you try to split up your mega-chunks of UI into composable, flexible components with a few props each.

10-Dec

Today's posts

Bundling with webpack and Parcel

OWASP ZAP

Creating composite components