"Little Johnny Tables". Um, yes, that was "Little Bobby Tables" [1]. Obviously not a big deal, but it seems emblematic of how sloppy this piece is. The article confuses – seemingly willfully, since Paul Vixie should know better – the concepts of dynamic language, dynamic page generation, lack of proper input hygiene, and various other orthogonal issues. The argument that dynamic languages are less secure depends an awful lot on the language – I don't think anyone is going to buy that C is more secure than Python. Haskell vs Python? Now that's a debate to be had. Certainly, websites that do no dynamic content generation are probably more secure – but then you're stuck with the Internet circa 1993. And of course, nobody is in favor not sanitizing inputs properly.<p>[1] <a href="http://xkcd.com/327/" rel="nofollow">http://xkcd.com/327/</a>
I'm not concerned if a web app or a shopping cart is dynamic. But I see dynamic blogs all the time. Blogs with no comment system, or one that's used infrequently. What's the point of making that dynamic?<p>While I'm on the subject, can anyone tell me the reasoning behind loading blog content with javascript? I hate when I visit a blog with no script turn on, and get greeted by a blank template. Why does it need javascript to grab the page content?
I've been an evangelist of static sites for a while. With over 15 yrs of experience doing sites I started in static and saw the "dynamic movement" born and grow (at some point I even programmed my own DCMS!); in most cases the motivation to install a DCMS was that the client wanted to update content in-house instead of paying a webmaster (a sound business idea?) but the reality is that even when using a dead simple DCMS clients always find it difficult to run it and still contact the webmaster. Furthermore, the vast majority of sites are seldom or never updated so having the 'kick me' sign in those cases is nosense. I guess a strong selling point of DCMS that made us all buy in even knowing that it was a bad idea where themes and plugins! So many of them, so nice looking, cross-browser tested and so easy to install. Clients where über happy with the end product.<p>So a couple of years ago I decided to do static sites for ALL my clients (there may be dynamic components that I normally implement with a back-end data service). I still have a few dozen sites and web apps with DCMS but the goal is to migrate them as well.
Ok, I understand that there's reasons for using static pages, but I don't get the feeling this guy really understands what he's talking about.<p><i>> Even if [..] and there's nothing like bash installed on the same computer as the web server </i><p>Bash installed? Huh? Why Bash exactly? I feel mentioning jails or containers here would be more on point..<p><i>> This is because every DCMS page view involves running a few tiny bits of software on your web server, rather than just returning the contents of some files that were generated earlier.</i><p>Sure, but guess how those pages are returned? By running code on the server..<p>It seems like hes real beef is with "dynamic" (vs staic) sites, but he keeps mentioning CMS's for some reasons (ike you can't can have "dynamic" sites witjout a cms)<p><i>> The web server executes no code on behalf of a viewer until that viewer has logged in..</i><p>1) Of course it does, 2) How do the site check your info without executing code? :)<p>etc etc..<p>There's a case for static sites, but this post just confuses things.
High traffic and high volume sites driven by CMSes, like newspapers, tv stations, etc., largely cannot rely on static files to deliver their content. Rather, they use caching layers for speed and security. There are two better ways to improve security for sites like these, which are highly targeted and poor candidates for static sites:<p>1) Use a headless CMS. WordPress on the backend that provides and API which is consumed by a Node app, for example.<p>2) Shift any user-facing dynamic feature off the CMS. Commenting, login, subscription management, etc., can be handled by purpose-built apps that tie into the CMS-driven site via Javascript, preserving the security and cacheability of the CMS.<p>That's not to say that it's impossible to drive a large-scale news site with static files. I believe CNN does exactly that with their in-house CMS. But no open-source CMS that generates static files is powerful enough to use in a newsroom context, or popular enough to gain traction.
A castle with no gate is also more secure. And kind of useless for its inhabitants. Like being under siege all the time.<p>My point being, sure you can get a more secure `something` by making it more and more static, but you'll probably cripple it somehow.<p>It's simply a balance you have to find for your use case.
I'd love to see how different people solve the highly dynamic plus static problem.<p>This usually boils down to the shopping cart and checkout example... you can always attack the checkout process as it is a unique, dynamic part of the process that no web store wishes to ever be unavailable.<p>How does one "go static" with web applications that by necessity involve interactions with datastores?
There was a submission briefly on the front page here where someone was proclaiming security by not using c/c++ for projects, yet, they left their blog comments and site wide open for some idiots who have already tried to post silly comments with JS popups.<p>I guess maybe we need people to use static sites, like trainer wheels on bikes, until they become more security concious.
Startup idea, free for the taking: create a service that "ossifies" dynamic websites into static HTML.<p>(By ossify, I mean to take something dynamic and make it static).<p>For example, that WordPress site you commissioned for a movie 3 years ago? Its a huge liability, but you don't have to take it offline - just ossify it. No one is updating that blog anymore!<p>Under the hood, it would basically be a crawler, and the deliverable would be a zip file containing a 1-to-1, static copy of their website with all URLs still working. I suspect most folks here could whip up a shitty proof of concept in 48 hours.<p>If someone does this, email me! I have a couple of potential clients for you (I'm a former consultant, with lots of WordPress sites in my history).
And there we have it. Security needs stability, stability decreases on a daily basis. We can't have that traditional kind of security. We need to move on to a more proactive way of thinking.
Static site is more secure only if the server is also up-to-date and setup properly to trim down all unnecessary options. Putting static site on a general purpose apache installation that will happily serve PHP and CGIs from user home dirs is not such a big security improvement.
Also, in times of SPAs, LocalStorage, WebRTC, Parse and FireBase you can sprinkle your static web-sites with some dynamic functionality, when needed...
I'm going to say that the bigger problem in dynamic languages isn't that they are dynamic. It's that they have weak, nonexistant, or very undeveloped mechanisms for creating strong communication protocols that you can depend on as safe or reliable.<p>Take the classic case of SQL injection. You have string input into your system that turns into string input into a SQL query that turns into string input to a database. That is dangerous because if you don't check on what the input string contains, it might contain nothing, or a semicolon, or it might not be a string at all!<p>We understand that putting a string direct into a SQL statement is dangerous at this point, but we have yet to fix its root cause - nonexistant protocols or boundaries in most code we write.<p>What a static language changes in that regard is compiler checked type signatures on your code. That generally stops you from say passing an Integer into something that needs a String. That solves a certain class of problems for sure, and the complier does it for you every time you change your code, so there is a convenience there.<p>What static typing doesn't give you is actual data correctness. Things like buffer overflows or SQL injection can still happen with static typing. You could use a language like Scala or Haskell to have stronger/more complex types that would have more distinct notion of value correctness and at that point the complier would be doing most of the work to ensure your program is correct.<p>Leaning on a type system in that regard is basically turning your types into the protocols that determine correctness in your system.<p>It is also possible to lean on stronger protocols that check messages in a dynamic languages to achieve largely the same thing.<p>In the end, to write safe, high quality software, you need to define the communication protocols between methods/functions/routines/services and enforce them much as you would with an externally facing REST api.<p>The difference between a dynamic system with dynamic protocol checking vs a static system with compiler type checking is the mechanism you are using to enforce the protocol and how easy it is to interact with it.<p>Dynamic systems might be easier to interface with externally because you don't have to understand a complex type, just pass a Hash/Dictionary sort of like a JSON API, vs a static system where you need to use the right types and so on, similar to a SOAP/WSDL API.<p>Performance is also a consideration, but really when you compare static vs dynamic, it is important to understand that at the end of the day you can write Ruby/Python/PHP that is functionally equivalent to C/C++/Java. They are all ultimately going to be able to do the same kinds of things.<p>The tradeoff is in how they solve the problem and how well that fits with the team writing the software.
Interesting. Also if you are interested read <a href="http://programmers.stackexchange.com/questions/206558/why-does-the-us-government-disallow-dynamic-languages-for-secure-projects" rel="nofollow">http://programmers.stackexchange.com/questions/206558/why-do...</a>