6 threats of the modern FE environment


Web’s frontend has always been a dynamic environment with it’s own specific characteristics. It has gained a lot of professionalism regarding job roles, technologies, processes and as a platform in the last years. But besides this evolutional change, frontend plays a growing role in multi device strategy and application architecture. This evolution, shift and growth can also introduce some possible threats that, if not addressed, can lead to disaster.


Our frontend domain is maturing rapidly. We started with a relatively simple web design environment and are entering a full-blown system development platform where we use professional development methodologies that have a high learning curve. Thorough knowledge of structured and Object oriented programming and design patterns like MVC, module, AMD etc is needed. We are continuously shifting away from the open low-level character of our web standards. The user environment is also rapidly expanding. A plethora of devices and browsers must be served. Users are getting more demanding regarding their experience. Browsers are evolving from an agent to a platform where new technologies are growing like a herd of mushrooms.All these new features drive an unstoppable temptation to bloat our frontend environment with all kinds of goodies, resulting in a full fat overloaded client where everything is happening without any goal or fundamental reason.If we don’t continuously reduce complexity, we will end up with a unmanageable environment.


Ignorance of the fact that the frontend environment is an environment with it’s own specific habits, requirements and behavior, and the fact that frontend developers are professionals that are aware of these specific characteristics, can be an important threat. The frontend environment should not be treated as a server side environment, like java or c#. We have to deal with an unstable, unreliable hostile runtime environment, build on a single threaded execution model. we don’t have compilers that save us from all kinds of mistakes. We struggle with runtime isolation, etc.

Agile development methodologies have morphed multi disciplinary teams into omni disciplinary teams where frontend developers have to test and backend developers have to write frontend code. No problem with that. This LEAN approach surely has potential, but it will only work with ignorance-free backend developers. They should be aware of the pitfalls, quirks and best practices of FE development. But we as FE professionals have to make them less ignorant by sharing our FE knowledge.

Complex environments need structure and some level of architectural foundation to keep them maintainable, so for the Frontend environment. We have come a long way from table-based web design to the current state. A lot of clever technologies and methodologies have been invented that contribute to the initial foundations of the web and have become de-facto standards. Patterns like REST, Progressive enhancement, Graceful degradation, Accessibility, semantics are great goods. Don’t ignore them.


The continuously diverging landscape of devices we have to support, and the ever growing richness of the user interface we have to build in order to server the demanding user’s online responsive experience, is asking a lot of our technologies and us as developers. Old design paradigms like ‘pixel perfect’, ‘page-design’ and ‘wireframes’ don’t fit to this complex new world. They create a lot of friction, don’t ignore.


Don’t think of the future as a goal, but as a process. Not only new technologies are entering our FE world with an amazing speed, but also the way’s we use them do do stuff are. Future in FE terms is now + 3 months. This means we have to be ready to absorb the future by providing flexibility and agility in our FE architecture. One other big threat in regard to future is to use new technologies or methodologies as a goal on their own, instead of means to reach a goal. Don’t let you be influenced by buzz driven people.


Our frontend environment has always been a very open, easy to use environment with technologies that have a low learning curve and where it is easy to book visible result. FE sourcecode files are easy editable and deployable to any environment, locally or remote.We only need a browser to view the result of our work. This openness has been one of the drivers for the growth and widely use of the web.In fact, anyone can build a webpage. But bit by bit we are raising barricades and thereby influencing the openness in a negative way. Complex tooling, abstractions, automation, mix-ins, etc. are good means to make our daily life easier and add more structure to our environment, but don’t overdo. Don’t make things difficult when they could be easy.


FE development has always been a discipline with some aspects of uncertainty. The most annoying perhaps has been the deviating level of browser compliance to web standards. But today the most important uncertainty are the things that lay ahead of us. What does our FE future look like. What technologies will arrive and which devices do we have to serve? Will my current knowledge still be sufficient? which developments should i track? All questions that will constantly pop up, every day of your FE life.

Like i told, future is a process. But don’t let this uncertainty scare you. Embrace it, treat it like a gift. Just be sure you have enough flexibility and agility in your architecture, so you can adapt quickly.

3rd party includes, avoid a hangover!


With the ever growing attention for social media, a lot of new SAAS-like solutions for adding additional functionality to a website are conquering the market. Through mash-up constructions, solutions are offered for bannering, widgets and tracking. These solutions often will load static content from a web server owned by the party offering the solution. This static content consist of javascript, css, html and image files.

The advantages of these SAAS solutions like easy integration and a efficient update-model are well known, but there also are some important risk that should thoroughly be evaluated before proceeding with these 3rd party includes.

Because 3rd party includes are loaded from a domain other than the origin of the actual HTML document, the browser will default to the same-origin-policy handling. This policy for example won’t allow these 3rd party scripts to use XHR for sending client data back to the 3rd party server. In a lot of situations, this same-origin-policy will be circumvented by creating hacks using browser flaws. As a result, these hacks will allow the 3rd party scripts to:

  • – Instantiate browser plugins
  • – Open popup windows
  • – Submit forms
  • – Use client side storage mechanisms like LocalStorage, SessionStorage, Cookies etc.
  • – Send XHR’s
  • – Manipulate the DOM of the origin page
  • – Use HTC’s and Binary behaviors or bind data

An other known side effect of 3rd party includes are the so called 4th party includes, when SAAS solution providers also include external resources in their sources. These could be for example libraries from a CDN or other delivery network. This construction can introduce some nasty effects that will influence the overall quality of our websites and applications.


3rd and 4th party content owners can have a different regime or strategy in terms of caching and performance than you try to strive for. Poor or no cache settings and a poor optimization for file size and amount of io of the external sourcesĀ  can result in a bad overall performance of our systems. Any downtime of this external environment or resulting 500 or 404 responses even can block or stall the render-thread of the browser (white screen). The result can be an introduction of SPOF (Single Point Of Failure) on the frontend.


3rd party scripts are able to see, store and post everything the user does without any consent of you or the user. Even as a result of the expanding chain-of-trust it will be much harder or even impossible to comply to privacy regulations or perhaps even our own privacy goal. A more for the user visible effect will occur if a 4th party uses click behavior for retargeting purposes.


Because existing browser security policies are bypassed, the risk that the integrity of your systems (websites, applications) is affected, will be increased. Besides the possibility of actual exploits or attacks via XSS, an another great danger is the unnoticed realization of drive-by malware infections because of compromised 3rd and 4th parties. Frequently stories appear in the news about websites been compromised by for example the 3rd party banner network they use. Such latter case is of course extremely damaging to a corporate reputation. As a high-volume site will be popular victims.

Governance / Control

The 4th party phenomenon can result in a mush of sources and origins (domains), where the complexity of the whole increases, and the span-of-control will alarming decrease.


To cope with these issues in a sound way, it is important that awareness is created regarding 3rd party includes and the possible risks. A clear vision regarding the above should be formulated and translated into a policy. For example, a thorough risk analysis and assessment could be done. And when necessary some quality requirements could be issued through SLAs with the 3rd party. There are some interesting technically developments going on to deal in a professional way with the same-origin-policy issue when embedding 3rd party content. Things like CORS, CD Messaging and HTML5 Sandbox will in the near future be good solutions to these problems, but until then, risks should be reduced otherwise.