Do web-developers need to catch-up?
When the first commercial website development agencies began to appear in the mid 1990s, their technical staff who's job was ultimately to produce code, were given job titles like "Webmaster" and "Web developer". Even as a "Web-Designer", you'd be expected to know your way around Macromedia Dreamweaver or MS FrontPage, as well as Adobe Photoshop*.
The people who filled these roles were typically new to code and programming concepts, and what "code" they did produce, was at the time restricted to HTML, CSS (when the browsers of the time began to support it) and snippets of JScript, JavaScript or even VBScript**.
But throughout the history of web-development, there's been this persistent "smell", a perception that established programmers of embedded software, firmware and packaged software, having proven themselves from the 50s and 60s through to the 90s, and who held themselves up to robust processes with respect to software testing and security, were always inherently "better".
For many of us who worked as a web-developers, before and after the dot com era, we don't immediately recall input sanitisation, cross-origin request forgeries or script injection as ever having crossed our employer's mind or those of our colleagues, let alone our own until relatively recently***.
There's at least an entire decade of being paid to build things for people, we'd probably have been doing at home anyway. Being a web-developer at the time was just the best job in the world, and we loved it.
But somewhere between 1995 and 2005, agencies began to be asked by their clients to add complex "backends" onto their otherwise static websites. An industry body here in New Zealand whose website was built in Dreamweaver, requested a searchable library of periodicals, product catalogues and news articles. It was delivered, written in php3 in 1999, and today, it wouldn't last a minute against any modern security professional.
Because at the time, security was barely even an afterthought.
That is though, until it was, when clients started to pay for it. No-one can be sure when that started, and it differed of course for everyone, and from country to country, agency to agency.
Regardless of the when, experience suggests it was only ever paid lip-service to. Security couldn't be interacted with. It wasn't a shiny UX component, you couldn't add a border-color to it, it wasn't tangible.
Recommended by LinkedIn
And for those who over time, saw its importance and worked it into their development processes, even they rarely possessed what's since become known as the Security Mindset, described here by Bruce Schneier back in 2008, and which appears to be at least still partially true today:
Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don’t have to exploit the vulnerabilities you find, but if you don't see the world that way, you'll never notice most security problems.
Nowadays, almost no software is installed via tape, floppy disk or a CD-R. It's ready-made, and available through a web-browser. It's there for everyone to use and of course for others to game, hack, deface and render inaccessible for monetary and political gain. The stakes have never been higher.
So do we think it fair to ask how long it will be for web-developers to "catch-up"?
Or is there an entire "lost" generation of us, raised in an agency context, who now manage developers ourselves, or even run agencies, for whom stability, risk and security can never quite reach front of mind, despite its strengthening mandate by modern customers in RFPs and SLAs?
But of course, the question itself is misleading. It isn't really whether web developers will catch up, but whether organisations will build the culture, training, and tooling to ensure that they do.
* Or Macromedia Fireworks, Illustrator or even Flash!
** Yes, browsers used to allow developers to embed client-side script written in VBScript (and they still do).
*** Let's say 2009 for argument's sake.
Oh, I remember well - those were the days when a web developer was also a designer, a database engineer, a front-end developer (forced to hack for all the IE versions), a programmer, and a DevOps engineer. Nice screenshot - I used VIM quite a bit and then Textmate.