Free ebooks and reports Security and Frontend Performance Breaking the Conundrum Sabrina Burney and Sonia Burney Security and Frontend Performance by Sonia Burney and Sabrina Burney Copyright © 2017 Akamai Technologies All rights reserved Printed in the United States of America Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472 O’Reilly books may be purchased for educational, business, or sales promotional use Online editions are also available for most titles (http://oreilly.com/safari) For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com Editors: Virginia Wilson and Brian Anderson Production Editor: Colleen Cole Copyeditor: Charles Roumeliotis Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Rebecca Demarest January 2017: First Edition Revision History for the First Edition 2017-01-13: First Release The O’Reilly logo is a registered trademark of O’Reilly Media, Inc Security and Frontend Performance, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work Use of the information and instructions contained in this work is at your own risk If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights 978-1-491-97215-1 [LSI] Chapter Understanding the Problem More often than not, performance and security are thought of as two separate issues that require two separate solutions This is mainly due to the implications posed behind various performance and security products We typically have either security solutions or performance solutions, but rarely solutions that offer both As technology has advanced, so have our attackers, finding newer and better ways to impact both the performance and security of a site With this in mind, it has become even more critical to come up with solutions that bridge the gap between security and performance But how we that? We need to shift the focus to what we can at the browser by leveraging various frontend techniques, such as web linking and obfuscation, versus solely relying upon the capabilities of a content delivery network (CDN) or the origin We can take advantage of all the new and emerging frontend technologies to help provide a secure and optimal experience for users—all starting at the browser Challenges of Today: Rise of Third Parties Many of the recent web-related concerns stem from an increase in web traffic as well as an increase in security attacks More specifically, many of these concerns arise due to the presence of embedded third party content Third party content is a popular topic due to the many risks involved, including both the potential for site performance degradation as well as the introduction of security vulnerabilities for end users Let’s discuss some of these issues in detail before diving into techniques to address them Web Traffic The latest trends suggest an accelerated increase in overall web traffic; more and more users access the Web through mobile and desktop devices With the growth in web traffic and ultimately bandwidth, end users continue to demand improved browsing experiences such as faster page loads, etc Keeping that in mind, we not only need to adapt our sites to handle additional user traffic, but we need to so in an optimal way to continue delivering an optimal browsing experience for the end user One of the higher profile frontend issues arising today is single point of failure By definition, single point of failure is a situation in which a single component in a system fails, which then results in a full system failure When translated to websites, this occurs when a single delayed resource in a page results in blocking the rest of the page from loading in a browser Generally, blocking resources are responsible for this type of situation due to a site’s dependency on executing these resources (i.e JavaScript) before continuing to load the rest of the page Single point of failure is more likely to occur with third party content, especially with the increase in web traffic and the obstacles in trying to deliver an optimal experience for the end user Attacks on the Rise While web traffic continues to grow, security threats continue to increase as well Many of these threats are motivated by financial means or for the purposes of harvesting data, while others execute distributed denial of service (DDoS) or spamming attacks to bring down origin web infrastructures.1 When discussing security, many different areas can be targeted during an attack, including the end user and/or the origin infrastructure While security at the origin is important, providing a secure browsing experience for the end user is equally important and is now the focus as security threats continue to rise Given the guarantee of a secure experience in the browser, end users are more likely to return to a site without having to worry about compromised content affecting their experiences As the effort to support increased web bandwidth and security threats continue, so does the need to adapt our sites to handle the increased load in an optimal and secure way for the end user Today, attackers are targeting vendor-related content due to the fact that proper security measures are not always in place and verified with third party content From Alexa’s Top 100 domains, pages on average fetch 48 embedded first party resources while fetching 62 embedded third party resources Based on these numbers, we can see how heavily reliant websites are on third party content— including fonts, images, stylesheets, etc Because of this dependency, websites are exposed to vulnerabilities like single point of failure and the potential for delivering malicious content to end users Technology Trends Based on the latest issues, we need solutions to bridge the gap and address both performance concerns as well as security holes at the browser level—and some of the latest technologies just that Taking a look at service workers and HTTP/2, these are both technologies aimed at improving the browsing experience; however, both of these methods are restricted to use over a secure connection (HTTPS) These technologies are ideal in demonstrating how solutions can improve both performance and security for any given website Other frontend techniques exist to help mitigate some of the security and performance vulnerabilities at the browser Leveraging , Content-Security-Policy, HTTP Strict-Transport-Security, and preload/prefetch directives prove to help protect sites from third party vulnerabilities that may result in performance degradation or content tampering Start at the Browser The main idea behind all these technology trends and frontend techniques is to help provide a secure and optimal experience for the end user But rather than focusing on what a content delivery network, origin, or web server can do, let’s shift that focus to what the browser can Let’s start solving some of these issues at the browser In the remaining chapters, we will go through each of the frontend techniques and technology trends mentioned at a high level in this chapter We will review implementation strategies and analyze how these techniques help achieve an end user’s expectation of a secure yet optimal experience, starting at the browser “Takeaways from the 2016 Verizon Data Breach Investigations Report”, David Bisson, accessed October 13, 2016, http://www.tripwire.com/state-of-security/security-data-protection/cybersecurity/takeaways-from-the-2016-verizon-data-breach-investigations-report Chapter HTTP Strict-Transport-Security Based on recent conference talks and development in technology, we see that society is moving towards secure end user experiences The examples of service workers and HTTP/2 working strictly over HTTPS demonstrates this movement; additionally, Google announced in late 2015 that their indexing system would now prefer indexing HTTPS URLs over HTTP URLs to motivate developers to move to HTTPS Generally, the quick fix solution here is to enforce an HTTP to HTTPS redirect for the end user; however, this still leaves the end user open to man-in-the-middle (MITM) attacks in which a malicious end user can manipulate the incoming response or outgoing request over a nonsecure HTTP connection Furthermore, the redirect method adds an additional request that further delays subsequent resources from loading in the browser Let’s explore how HTTP Strict-TransportSecurity (HSTS), a frontend security technique, can address these issues What Is HSTS? The HTTP Strict-Transport-Security (HSTS) header is a security technique that enforces the browser to rewrite HTTP requests into HTTPS requests, for a secure connection to the origin servers during site navigation From HTTP Archive, 56% of base pages are using the HTTP Strict-TransportSecurity technique and this number will continue to grow as HTTPS adoption continues to grow Not only does this header provide browser-level security, but it also proves to be a frontend optimization technique to improve the end user experience By utilizing this header and the associated parameters, we can avoid the initial HTTP to HTTPS redirects so that pages load faster for the end user As mentioned in High Performance Websites by Steve Souders, one of the top 14 rules in making websites faster is to reduce the number of HTTP requests By eliminating HTTP to HTTPS redirects, we are essentially removing a browser request and loading the remaining resources sooner rather than later The example in Figure 2-1 demonstrates how the browser performs a redirect from HTTP to HTTPS, either using a redirect at a proxy level or at the origin infrastructure The initial request results in a 302 Temporary Redirect and returns location information in the headers, which directs the browser to request the same page over HTTPS In doing so, the resulting page is delayed for the end user due to time spent and additional bytes downloaded Figure 2-1 Redirect When using the Strict-Transport-Security technique in Figure 2-2, we immediately see an improvement in delivery due to the elimination of the HTTP to HTTPS redirect for subsequent non- secure requests Instead, the browser performs a 307 Internal Redirect for subsequent requests and a secure connection is initialized with the origin infrastructure From a frontend performance standpoint, initial header bytes are eliminated due to the removal of 302 Temporary Redirect and the page is delivered sooner to the end user over HTTPS Figure 2-2 Internal browser redirect with Strict-Transport-Security NOTE Keep in mind that an initial 302 Temporary Redirect or 301 Permanent Redirect is still needed to ensure the resulting HTTPS request returns the Strict-Transport-Security header; however, any subsequent requests will result in a 307 Internal Redirect at the browser and will continue to so until the time to live (TTL) expires, which is described in the next section The Parameters In order to take advantage of the Strict-Transport-Security header from both a performance and security point of view at the browser, the associated parameters must be utilized These parameters include the max-age, includeSubDomains, and preload directives: Strict-Transport-Security: _max-age_=_expireTime_ [; _includeSubDomains_] [; _preload_] The max-age directive allows developers to set a time to live (TTL) on the browser’s enforcement of a secure connection to a website through the security header The optional includeSubDomains directive allows developers to specify additional pages on the same website domain to enforce a secure connection Lastly, the optional preload directive allows developers to submit sites to a StrictTransport-Security list maintained on a per-browser basis to ensure that secure connections are always enforced Preload lists have various requirements including a valid browser certificate and a full HTTPS site including subdomains Last Thoughts With a simple security technique, we eliminate man-in-the-middle (MITM) attacks over a nonsecure connection While this method proves successful, the security protocol should be investigated to ensure MITM attacks can be avoided over a secure connection as well Several SSL and TLS versions have exploitable vulnerabilities that should be considered while moving to a secure experience and deploying this security enhancement Chapter Service Workers: Analytics Monitoring Let’s jump right into the first application of service workers, analytics monitoring Performance Monitoring Today Over the last few years, third party performance monitoring tools have gained a lot of traction due to all the benefits they provide for most businesses The reason these tools have had a significant impact on businesses is because of all the powerful data they are able to provide More specifically, these tools are able to monitor performance by collecting timing metrics, which are then correlated to various revenue growth or even conversion business metrics Businesses are then able to make logical decisions based on these key performance indicators (KPIs) to improve the end user’s experience overall and gain that competitive edge over other businesses Many popular performance monitoring tools exist today, as shown in Figure 7-1; some are in-house, but the majority are third party components that are able to collect and present the data in a logical way Figure 7-1 Performance monitoring tools Each of these has unique capabilities bundled with the data and metrics they provide for measuring performance Some measure performance over time versus others that measure single snapshots or even request transactions And of course, some take the approach of real user monitoring (RUM) versus simulated traffic performance monitoring So what third party analytics monitoring tools have to with service workers? Typically, these tools expose their services via REST APIs Given this approach, these tools are unable to track and provide data for offline experiences As we advance in technology, year by year, it is important to note that we are constantly coming up with new ways to provide new types of experiences for our end users If performance metrics have that much of an impact on the business and on the end users, then it’s critical that we provide that data for offline experiences Track Metrics with Service Workers The navigator.connect API enables third party analytics platforms to register service workers that expose APIs to track metrics, for both online and offline experiences As long as the services are available/implemented by service workers, we can use the navigator.connect API to connect to third party platforms In Example 7-1, note that we need to define two event handlers We need to first successfully install the service worker and connect to the third party platform via the activate event Then, during each fetch event, we can log and save pertinent metrics Example 7-1 Connect to third party API self.addEventListener('activate', function(event) { event.waitUntil( navigator.services.connect('https://thirdparty/services/ analytics', {name: 'analytics'})); }); self.addEventListener('fetch', function(event) { navigator.services.match({name: 'analytics'}).then( port.postMessage('log fetch')); }); These service workers are then able to report these metrics when connectivity is reestablished so that they can be consumed by the service Numerous implementation strategies exist for reporting the metrics; for example, we can leverage background sync so that we not saturate the network with these requests once the user regains connectivity Where Do Performance and Security Fit In? Why is leveraging service workers for third party analytics a potentially better solution than what we have today? Many third party analytics tools that provide RUM data require injection of a particular blocking script in the of a base page This script cannot run asynchronously and cannot be altered in any way The problem is that placement of a third party blocking script at the beginning of the page may delay parsing or rendering of the HTML base page content, regardless of how small or fast it is Mpulse and Adobe Analytics are good examples of tools that require blocking JavaScript at the of the base page By introducing third party content earlier in the page, the site is more susceptible to single point of failure or even script injection, if that third party content is compromised or the third party domain is unresponsive Generally, more popular third party performance tools are reliable, but there are some with security holes, or that cause performance degradation to the first party site Service workers remove the piece of monitoring code from the initial base page that collects and beacons out data to the third party platforms By placing the connect JavaScript logic in the installation event handler, we have less blocking client-side JavaScript that can run asynchronously, which reduces the risk for single point of failure or script injection attacks Thus there is no impact to the parsing or rendering of the HTML content Last Thoughts: Now Versus the Future If service workers can help third party performance monitoring tools go “unnoticed” to the site and end user, why are they not being leveraged everywhere already? As with any new technology, coming up with a standard takes time—time to vet, time to find the holes, and time to gain popularity Also note that third party platforms need to expose their services to service workers Many timing APIs have yet to include this functionality, such as Google’s Navigation Timing API Given their infancy, and the reasons mentioned above, service workers still have a long way to go before becoming part of the “standard.” Chapter Service Workers: Control Third Party Content Now let’s broaden the scope from third party analytics tools to all third party content More specifically, let’s discuss how to control the delivery of third party content Client Reputation Strategies When we talk about “control” with reference to unknown third party content, what often comes to mind are backend solutions such as client reputation strategies, web application firewalls (WAFs), or other content delivery network/origin infrastructure changes But with the increased usage of third party content, we need to ensure that we offer protection not only with these backend strategies, but also to our end users starting at the browser We want to make sure requests for third party content are safe and performing according to best practices So how we that? Let’s leverage service workers to control the delivery of third party content based on specific criteria so that we avoid accessing content that causes site degradation or potentially injection of malicious content not intended for the end user Move to Service Worker Reputation Strategies Note the simple service worker diagram in Figure 8-1 The service worker’s fetch event intercepts incoming network requests for any JavaScript resource and then performs some type of check based on a predefined list of safe third party domains, or using a predefined list of known bad third party domains Essentially, the fetch event uses some type of list that acts as a whitelist or blacklist Figure 8-1 Service worker diagram Let’s take this solution and build on it to make it an adaptive reputation solution In addition to the whitelist/blacklist, let’s come up with logic that can use the forward and block mechanisms of the service worker Specifically, let’s use a counter and a threshold timeout value to keep track of how many times content from a third party domain exceeds a certain fetch time Based on that, we can configure the service worker to block a third party request if a resource from a specific domain has exceeded the threshold X amount of times A Closer Look First, we need to handle the installation and activation of the service worker so that we make the initial list of third parties accessible upon worker interception of any incoming resource requests (Example 8-1) Example 8-1 Activate service worker self.addEventListener('activate', function(event) { if (self.clients && clients.claim) { clients.claim(); } var policyRequest = new Request('thirdparty_urls.txt'); fetch(policyRequest).then(function(response) { return response.text().then(function(text) { result=text.toString(); }); }); }); During the activate event, we can set up a connection to some list of third party domains The text based file could live at the origin, at a content delivery network, at a remote database, or at other places that are accessible to the service worker Now, as shown in the pseudocode in Example 8-2, when a resource triggers a fetch event, limited to JavaScript only in this example, we can configure the service worker to block or allow the resource request based on two conditions: the whitelist/blacklist of third party domains and the counter/threshold adaptive strategy Example 8-2 Fetch event handler pseudocode self.addEventListener('fetch', function(event) { // only control delivery of JavaScript content if (isJavaScript) { // determine whether or not the third party // domain is acceptable via a whitelist isWhitelisted = match(resource,thirdpartyfile) if (isWhitelisted) { getCounter(event, rspFcn); var rspFcn = function (event){ if (flag > 0){ // if we have exceeded the counter // block the request OR serve from an offline cache } } } else{ // send the request forward // if the resource has exceeded a fetch time if (thresholdTimeoutExceeded) { updateCounter(event.request.url); } // else nothing // add resource to offline cache cache.add(event.request.url); } } else { event.respondWith(fetch(event.request)); } }); Analysis Note the following method in particular: getCounter(event, rspFcn); This method fetches the current state of the counter for a third party domain Remember that, for each fetch event, we can gather a fetch time for each resource But the counter needs to be maintained globally, across several fetch events, which means we need to be able to beacon this data out to some type of data store so that we can fetch and retrieve it at a later time The implementation details behind this method have not been included but there are several strategies For the purposes of the example, we were able to leverage Akamai’s content delivery network capabilities to maintain count values for various third party domains Upon retrieving the counter value, we have a decision to make as seen in the implementation: updateCounter(event.request.url); If we have exceeded the number of times the third party content hit the threshold timeout for fetch time, as indicated by the counter value, then we can either block the request from going forward OR we can serve alternate content from an offline cache (An offline cache needs to be set up during the installation event of a service worker.) If we have NOT exceeded the counter, then we send the request forward and record whether or not it has exceeded the fetch time on this run, in this case, if it has exceeded 500 milliseconds If the resource hit our predefined threshold value, then we can update the counter using the updateCounter method Again, the implementation details for this method have not been included, but you will need to be able to beacon out to a data store to increment this counter If the resource did not hit the threshold value, then there is no need to update the counter In both cases, we can store the third party content in the offline cache so that if the next time a fetch event gets triggered for the same resource, we have the option to serve that content from the cache Sample code Example 8-3, shows a more complete example for the pseudocode in Example 8-2 Example 8-3 Fetch event handler self.addEventListener('fetch', function(event) { // Only fetch JavaScript files for now var urlString = event.request.url; if(isJavaScript(urlString) && isWhitelisted(urlString)) { getCounter(event, rspFcn); var rspFcn = function (event){ if (flag > 0){ // If counter exceeded, retrieve from cache or serve 408 caches.open('sabrina_cache').then(function(cache) { var cachedResponse = cache.match(event.request.url).then(function(response) { if(response) { console.log("Found response in cache"); return response; } else{ console.log("Did not find response in cache"); return (new Response('', {status: 408, statusText: 'Request timed out.'})); } }).catch(function() { return (new Response('', {status: 408, statusText: 'Request timed out due to error.'})); }); event.respondWith(cachedResponse); }); } else{ Promise.race([timeout(500), fetch(event.request.url, {mode: 'no-cors'})]).then(function(value){ if(value=="timeout"){ console.log("Timeout threshold hit, update counter"); updateCounter(event.request.url); // use promises here } else console.log("Timeout threshold not reached, retrieve request, w/o updating counter"); // If counter not exceeded (normal request) // then add to cache caches.open('sabrina_cache').then(function(cache) { console.log("Adding to cache"); cache.add(event.request.url); }).catch(function(error) { console.error("Error" + error); throw error; }); }); }};} else { event.respondWith(fetch(event.request)); }}); Last Thoughts There are numerous ways to implement the getCounter and updateCounter methods so long as there exists the capability to beacon out to some sort of data store Also, Example 8-3 can be expanded to count the number of times a resource request has exceeded other metrics that are available for measurement (not just the fetch time) In Example 8-3, we took extra precautions to ensure that third parties not degrade performance, and not result in a single point of failure By leveraging service workers, we make use of their asynchronous nature, so there is a decreased likelihood of any impact to the user experience or the DOM NOTE Just like JavaScript, service workers can be disabled and are only supported on certain browsers It is important to maintain fallback strategies for your code to avoid issues with site functionality The main idea behind this implementation is to avoid any unnecessary performance degradation or potential script injection by only allowing reputable third party content that meets the criteria that we set in place We are essentially moving security and performance to the browser, rather than relying solely on backend client reputation, WAFs, and other content delivery network/origin infrastructure solutions Chapter Service Workers: Other Applications Using service workers to control the delivery of third party content or even monitor third party performance is critical But what about first party resources? Or frontend techniques to improve the performance and security with base page content in general? Service workers can be leveraged in many different ways, including through input validation and geo content control, which are discussed briefly below Input Validation Input validation strategies typically involve client-side JavaScript, server-side logic, or other content delivery network/origin logic in an effort to not only prevent incorrect inputs or entries, but also to prevent malicious content from being injected that could potentially impact a site overall The problem with some of the above strategies is that a site still remains vulnerable to attacks With client-side JavaScript, anyone can look to see what input validation strategies are in place and find a way to work around them for different attacks such as SQL injections, which could impact the end user’s experience With server-side logic or other content delivery network/origin features, the request has to go to the network before being validated, which could impact performance for the end user How can service workers mitigate some of these vulnerabilities? Let’s use the service worker fetch handler to validate the input field and determine whether to forward or block a resource request Of course service workers can be disabled, as with JavaScript, but it is up to the developer to put backup sever-side strategies in place as a preventative measure Benefits of using service workers: Remove the need to have the request go to the network, server, content delivery network, or origin, which removes additional validation delay Reduce the risk of those requests being intercepted if we block them before even forwarding to the network Service workers have no DOM access so malicious content is likely not going to be injected to change the page and how it validates form fields The below pseudocode in Example 9-1 helps demonstrate how to implement input validation via a service worker The fetch event can catch the POST request and analyze the fields before submission Example 9-1 Fetch event handler for form submission self.onfetch = function(event) { event.respondWith( // get POST request from form submission // analyze fields before submitting to network if input field is valid submit fetch(event.request) else block ); }; Geo Content Control Delivering content to end users based on their specific geography has been critical to business growth Advanced technology available at the content delivery network or origin has allowed businesses to target end users with content based on their geo locations But what if we could make that determination at the browser, and then forward the request based on an end user’s geo location? Service workers can help by leveraging the GeoFencing API, which allows web applications to create geographic boundaries around specific locations Push notifications can then be leveraged when a user or device enters those areas But being a browser-specific technique, there is the security concern in spoofing a geo location With this in mind, it is critical to maintain server-side logic for comparison purposes, whether it exists at the origin or content delivery network, to ensure that geo location data is not tampered with This functionality is still relatively new because of the different caveats when accessing an end user’s geo location But the idea of moving this functionality to the browser, with possible access to an offline cache for geo-specific content, can help eliminate the need to make a decision at the content delivery network or origin, which could help improve performance A Closer Look Let’s take a look at Example 9-2 During service worker registration, different GeoFence regions would be added, along with any additional offline caches for content Example 9-2 Register event handler: Adding GeoFences navigator.serviceWorker.register('serviceworker.js') then((swRegistration) => { let region = new CircularGeofenceRegion({ name: 'myfence', latitude: 37.421999, longitude: -122.084015, radius: 1000 }); let options = { includePosition: true }; swRegistration.geofencing.add(region, options).then( // log registration ); // setup offline cache for geo-specific content }); Once the service worker is active, it can start listening for users or devices entering or leaving the GeoFence we set up during registration (Example 9-3) Example 9-3 GeoFence enter event listener self.ongeofenceenter = (event) => { console.log(event.geofence.region.name); //if offline cache has region resources -> serve content }; Because service workers can be disabled, having backend solutions in place is critical As an additional preventative measure, content delivery networks or the origin can validate geo location and geo-specific content being served back to the end user Last Thoughts Input validation and geo content control are just a couple more service worker applications, but the use cases and applications will continue to increase as we advance with this technology The idea is to take backend solutions and bring them to the browser in an effort to mitigate some of the common security and performance issues we see today Chapter 10 Summary Throughout this book, we have learned that a performance solution can be a security solution and a security solution can, in fact, be a performance solution In the past and up until now, the majority of the focus has been on improving conditions at the origin, by looking at web infrastructure Additionally, certain performance improvement techniques have been found to compromise security and vice versa, certain security techniques have been found to compromise performance This is mainly due to business needs End users demand an optimal browsing experience and they will continue to demand even faster and more secure browsing experiences That being said, we need to develop solutions that help bridge the gap between security and performance, by bringing the focus to the browser We have discussed major trends and prominent issues, including the concept of single point of failure as well as the possibility of delivering compromised content to end users As developers, it is important to recognize when these situations can occur so that we can better adapt our sites to handle unexpected behavior Much of the focus of this book has been on third party content due to the fact that third party providers are becoming increasingly popular as they are able to offload much of the work from companies’ origin web infrastructures End users are exposed to the many different risks mentioned throughout this book due to this, so we can see how the concept of bridging the gap at the browser is becoming increasingly important What Did We Learn? Over the course of this book, we have explored several existing techniques as well as newer technologies to help achieve an optimal frontend experience that is also secure Keep these simple yet powerful points in mind: Avoid the HTTP→HTTPS redirect on every page request! Use the HTTP Strict-Transport-Security technique to cache these redirects and potentially configure browser preload lists to continue enforcing an initial secure connection Protect your sites from third party vulnerabilities Sandbox, sandbox, sandbox….and srcdoc! Utilize the new directives introduced in HTML5 and corresponding Content-Security-Policy directives to better address third party concerns Explore the latest on referrer policies While still experimental, adopting these practices in your sites will better ensure privacy for your end users Improve content delivery in a secure way Consider pairing preload and prefetch web linking techniques with Content-Security-Policy to gain a security enhancement in addition to a frontend optimization technique Deter attackers that target your vendor content by obfuscating the sources in an optimal way Explore service workers! While still considered new, explore the latest with service workers as they can be powerful especially when bringing security and performance enhancements to the browser Service workers provide more control including geo content control and input validation methods, as well as monitoring third party content (analytics code, ad content, etc.) Last Thoughts Remember to enhance techniques that exist today using the methods described throughout this book Additionally, stay up-to-date with the latest technologies and look for newer ways to bring a secure and optimal experience to the end user While security can be a vague term, there are many different areas that are often dismissed Origin web security is usually the focus, but it is important to consider the different flavors of security including privacy for end users, as well as the ability to conceal information from potentially malicious end users Compromising security for a performance solution and vice versa is no longer an option given the latest trends Let’s continue thinking about solutions that provide benefits in both areas as the need continues to increase About the Authors Sonia Burney has a background in software development and has been able to successfully participate in many roles throughout her years at Santa Clara University and in the tech world Every role, at every company, has driven her to learn more about the tech industry, specifically with regards to web experience and development While Sonia’s background consists of mostly software development roles within innovative teams/companies, her current role at Akamai Technologies now includes consulting and discovering new solutions to challenging problems in web experience— specifically, coming up with algorithms designed to improve the frontend experience at the browser Outside of work, not only is she a dedicated foodie, but she enjoys traveling, running, and spending time with friends and family Sabrina Burney has worked in many different fields since graduating from Santa Clara University She has a background in computer engineering and has always had a passion for technologies in the IT world This passion stems from learning about newer tech being developed as well as enhancing tech that is already present and underutilized While Sabrina currently works at Akamai Technologies, her experience inside and outside of Akamai includes roles in software development and web security, as well as more recently the web experience world She is able to utilize her backgrounds in multiple fields to help improve the overall end user experience when it comes to navigating the Web Sabrina’s recent work is focused on third-party content and ways to improve the associated vulnerabilities and concerns—she has several patents pending in this subject area Outside of work, she enjoys playing soccer with her fellow coworkers as well as traveling with her family ...Free ebooks and reports Security and Frontend Performance Breaking the Conundrum Sabrina Burney and Sonia Burney Security and Frontend Performance by Sonia Burney and Sabrina Burney Copyright... newer and better ways to impact both the performance and security of a site With this in mind, it has become even more critical to come up with solutions that bridge the gap between security and performance. .. demonstrating how solutions can improve both performance and security for any given website Other frontend techniques exist to help mitigate some of the security and performance vulnerabilities at the