Esbuild is a blazing-fast JavaScript bundler and minifier, and comparing versions 0.11.14 and 0.11.15 reveals subtle improvements relevant for developers focused on performance and efficiency. Both versions operate under the MIT license and share the same core description, emphasizing esbuild's speed advantage. The key differences lie in the dist data, specifically the unpackedSize and releaseDate. Version 0.11.15, released on April 26, 2021, features an unpacked size of 86371 bytes, a subtle increase from version 0.11.14's 81679 bytes released two days prior.
While seemingly insignificant, this 4692 byte increase suggests possible enhancements such as bug fixes, new features, or internal optimization. Developers should always consider incremental size changes, even small ones, as they can impact load times, especially in larger projects. For those prioritizing bleeding-edge stability and comprehensive testing, sticking with the slightly older 0.11.14 might be preferable. However, developers looking for the latest improvements and are willing to accept the potential for minor, undiscovered issues will likely benefit from upgrading to 0.11.15. Both versions offer compelling arguments, so choose based on your project's specific needs and risk tolerance for any newly committed code changes. The core functionality of a fast bundler remains consistent in both versions, making either a solid choice for speeding up your build processes. This package is useful for frontend development, improving website performance.
All the vulnerabilities related to the version 0.11.15 of the package
esbuild enables any website to send any requests to the development server and read the response
esbuild allows any websites to send any request to the development server and read the response due to default CORS settings.
esbuild sets Access-Control-Allow-Origin: * header to all requests, including the SSE connection, which allows any websites to send any request to the development server and read the response.
https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L121 https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L363
Attack scenario:
http://malicious.example.com).fetch('http://127.0.0.1:8000/main.js') request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above.http://127.0.0.1:8000/main.js.In this scenario, I assumed that the attacker knows the URL of the bundle output file name. But the attacker can also get that information by
/index.html: normally you have a script tag here/assets: it's common to have a assets directory when you have JS files and CSS files in a different directory and the directory listing feature tells the attacker the list of files/esbuild SSE endpoint: the SSE endpoint sends the URL path of the changed files when the file is changed (new EventSource('/esbuild').addEventListener('change', e => console.log(e.type, e.data)))The scenario above fetches the compiled content, but if the victim has the source map option enabled, the attacker can also get the non-compiled content by fetching the source map file.
npm inpm run watchfetch('http://127.0.0.1:8000/app.js').then(r => r.text()).then(content => console.log(content)) in a different website's dev tools.Users using the serve feature may get the source code stolen by malicious websites.