It is not difficult to operate software in a secure environment: disconnect from the Internet, move the host computer into a vault, and limit physical access to vetted users. This is exactly how governments protect their most sensitive information. Obviously this solution won’t work for businesses, but it does illustrate a good security plan most consider more than security. The right security plan provides sufficient protection at a reasonable cost. Still, it is not easy to determine what is sufficient protection and what is a reasonable cost. These are not values businesses can accurately measure, and without good metrics it becomes difficult to arrive at objective answers. This lack of quantitative objectivity is one reason why a search of the web finds so many varying opinions on web security (with ample references to support each camp’s mindset). It is also one of the reasons seasoned security experts recommend not becoming hung up on the security debates or the technical details, but to instead focus on the broader security picture.
When considering applications, one cannot get very far into a broader security outlook without encountering the question of application platforms: HTML5 versus native versus hybrid solutions. One might rightly say the security roadmap for applications is dominated by the platform choice. So which platform is best for security? Again, we can’t offer qualitative analysis, but it is possible to step back and observe how the platform choice affects security in the broadest sense.
A survey of the web-security literature might be boiled down to the following general conclusions when considering application platforms.
- Native applications typically have an edge in providing the highest level of security, but at the highest development cost.
- Hybrid HTML5 applications running in a native container come in a close second (or perhaps tying with a very secure container), but at a substantially lower cost.
- Web-based HTML5 comes in third with more exposure, but it is still capable of providing sufficient security for most applications, doing so at the lowest cost.
However, at ChartIQ we believe there are broader implications for security that tilt the scales more in favor of HTML5 than reflected above. Before getting into why, let’s first review where HTML5 is now positioned with security:
- All the major IT vendors are behind HTML5, have every intention of staying behind it for the long-term, and will continue to improve on its underlying security model. Given security is not a static problem, a platform requires ongoing security support and refinement.
- HTML5 is designed with a security emphasis, with browsers running each HTML5 window in a secure sandbox. Communication in and out of the sandbox is limited to standardized APIs, again designed with security in mind. No doubt these APIs are inherently the source of all security risks, but the scope of the security problem is substantially narrowed.
- HTML5 is hardware independent, so one model fits all deployments. This is a monumental advantage to all aspects of development including security.
- HTML5 is now used in the majority of applications being built. While this popularity means it is at the center of the security battles, it also means a company using HTML5 will be at the center of the herd with strong allies. (No IT manager wants to be left alone to deal with security exposures arising from legacy technology.)
- With a hybrid platform, HTML5 applications can be built on a very secure native container, matching most if not all of the native security advantages. (At ChartIQ our Finsemble initiative supports desktop HTML5 solutions running under OpenFin’s secure operating layer.)
HTML5 can provide sufficient protection to meet the needs of most applications, with the highest commercial security requirements covered by an HTML5 hybrid solution. One might even say HTML5 is the best security bargain available — nowhere else will you find the same measure of protection delivered per unit of cost. However, it is the indirect security advantages that may ultimately tilt the security scales the most.
It is telling that Gartner in its “State of Application Security, 2016” doesn’t mention the underlying platform once, instead it points out “Application security is still mostly improvisation”, then explains how improvisation is a flawed approach. This improvisation is a direct result of a lack of education…from a security coding perspective and a security process perspective. In fact the underlying security platform becomes almost irrelevant when developers aren’t properly trained to use it. Education may be the single-most crucial ingredient affecting security risks and costs.
Fortunately, HTML5 makes it is easier to educate development teams on security. Why? First, with HTML5 the security aspects of only one platform must be learned, as opposed to one for each native platform. Second, no other platform has the same level of educational support, whether it be books, blogs, academic papers, industry training, or supporting tools. Also, as previously mentioned, HTML5 has a well-defined security model with the risks narrowed to APIs in and out of the browser sandbox, narrowing the scope of the problem. For example, All You Wanted To Know About HTML5 Security succinctly outlines in a few pages much of what developers need to know for the dominant APIs — this advice alone can greatly improve many product’s security.
Once properly educated, development teams can build secure HTML5 applications…if given the time. This brings us to another key but indirect consideration: Security is invisible within products, making it one of the first places to skimp when product resources or schedules are tight.
Fortunately, HTML5 development provides teams with more time to focus on security. This may initially sound like contrived reasoning, but there is no contention that HTML5 products are easier and faster to build compared to native solutions. There is also no contention that an HTML5 solution applies to multiple platforms. As already mentioned, this is in direct contrast to native solutions (e.g. Windows, OSX, iOS, Android, Windows Mobile) where security concerns multiply, development resources expand, the right talent becomes harder to find, and coordination becomes more difficult. Also, as teams become better educated on security, you will see it directly surface in development processes, with time explicitly provided on schedules.
In a nutshell, today broader security planning should have less focus on technology and more on the practicalities of executing an effective security plan. Education and development time are now the essential prerequisites, both of which are easier to come by using HTML5.
