You can also build horribly insecure applications with a framework. A framework does not absolve you from thinking, which seems to be the point the author is making.

There's a difference between frameworks and libraries and of course it is a good idea to use trusted crypto implementations and avoid NIH syndrome, but a large part of security is including it in the design process from the start.

You can't just assume "the framework will handle it", or "bcrypt is all I need" or "the opsec team will find all the problems".

It rather sounds like you're expecting the author to hand you a magic-bullet solution, which is rather the whole point of the article: there isn't one. You do need to know what you're doing.

The jack of all trades is the master of none. Almost no generalist is going to be good enough to properly handle all security concerns. I like knowing my framework is constantly upgrading password handling, XSS attack prevention and things I haven't even heard of yet. The fact you can build insecure things in a framework isn't an argument against it and why would someone who builds a horribly insecure app in a framework produce a better result without using one?

They probably wouldn't, but that's neither something I said, nor is it the article's premise.

However, a framework does increase the attack surface, which is something that should be taken into account. If you save 20 lines of code by adding a 100,000 line framework, you need to ask yourself which of those is most likely to contain a bug?

Plus, bugs in popular frameworks tend to get exploited in practise. Other bugs less so, because of the need to first find the bug. The odds of that happening will increase if the bug is common and obvious, or you are a particularly high-value target. By using a framework you effectively increase your value as a target to the sum value of all projects using that framework. This becomes especially bad if the framework stops being maintained, because the value to an attacker isn't lost as quickly.

The above also applies to libraries, but libraries tend to be more focused and more stable than frameworks, since frameworks tend to "go stale" if not continually updated in a way that most libraries do not.

Who is to say your framework of choice isn't written by generalists just like the generalist your creating the straw man argument against?

> You can also build horribly insecure applications with a framework

"You can also find sober drivers that cause accidents". Of course, but it doesn't invalidate the fact that drinking and driving is a bad combo and puts you and others in greater danger statistically. It's sort of similar here.

You may be drowning in the kool-aid. It is very easy to write tiny secure code in PHP without a framework. Of course if you're building a social network, then it will run into some of those potential security issues. But for most of the small problems you're using PHP to solve, you really don't need to be a security expert as long as you're not piping user input directly to your database or OS.

It's kind of the point of the whole page - you don't need a massive general framework to solve your specific problem. Maybe read the whole thing instead of just skimming it.

No it's not easy. You need to be sure you escape everything, setup a mecanism for allowed host, CSRF, anti click-hijacking and of course ensure your auth workflow is nicely designed.

And that supposes that not only you know about it, but also how to implement it properly. Not to mention the time to code it, document it, test it and maintain it.

Most custom PHP site I encounter are full of gigantic holes.

And then other developpers comes in, and have to learn how to use your non standard code, that is unlikely to be half as well written, tested or documented than standard solutions.

Of course custom code has also a cost, which means doing all that, even not very well, will take a toll on the budget, which you can't spend on other security aspects. All that while security is generally the last item on the budget list.

> And then other developpers comes in, and have to learn how to use your non standard code

If you use a framework, new developers coming in often have to learn how to use it as well.

I've never hired a developer who didn't know how to use PDO prepared queries, which are the standard in my code base. Built into the language, escapes no matter what database you use, etc.

Good developers know how to write secure PHP code without a framework. They don't necessarily know how to use a random framework.

Bad developers will at some point take variables from a $_POST/GET array and use them unwisely regardless of whether you have a framework.

If its under 50 lines of code for some simple processing, I don't think another developer who comes in would have much trouble. Of course if that 50 lines of code is now 250 because it tries to get around a framework, then instead of finding a PHP developer to help out on the code, you now need a $framework developer.

Basically, don't use a framework unless you really do need all the features it gives you. Don't just pick a framework and try to cram your code into it for the sole purpose of using a framework.

> If its under 50 lines of code for some simple processing

It doesn't matter how much lines you write. It has nothing to do with the number of lines but the functionalities and how many developers review that piece of code. Furthermore more a third party codebase is usually the code you don't have to test. You keep on talking about frameworks like it's a bad thing, but all frameworks are not equal in size nor features.

You still don't need a framework for that. Just use composer to install a bunch of well-tested, feature-rich, but fully independent packages. Start your script with

    include 'vendor/autoload.php';

and add 50 lines of your own code.

Don't forget to understand how/why/what those other packages do.

Including a package based on the contents of its packagist description alone is basically like reading the ingredients for a pizza and then eating a bag of flour.

It's the same with frameworks. "Modern PHP" frameworks usually include a ton of composer packages.

So pick a better one.

I think RyanZAG was referring to solving one small problem with a PHP script. That does not necessitate a web page or any of the security mechanisms you suggest.

There is no such things as a "general purpose" framework anyone would use for such a small script. This would make no sense.

Also, he mentions that company uses framework, won't scale and start ripping it apart to take unnecesary parts. You don't do that for a 50 line script

You often do though: as in, if each independent problem was handled by a microservice PHP script, it would just be a 50 line script.

But if you've built it on top of a huge framework then you can end up with all the separate parts stuck together in a massive project where you're not even using 75% of the framework.

Theres a few things here.

1.- Massive project where you're not using 75% of the framework.

Let's say i don't want the template engine and the ORM, the framework should let me pull them out. If i need them at some point i'll pull them in. But i know that when i do, these things will be maintained and working.

And this is where a good framework shines. No need to deal with a dependency hell, and you should be able to pull out easily what you don't need.

Edit: If you're just using a 25% of a framework and have no prospects on using it maybe you should look for something smaller

2.- Separate parts stuck on a massive project

Thats not the framework fault but yours. You should write the parts of the application in a way that you can reuse them in another project, using the same framework or in a similar framework with as few changes as possible. And also its part of your work knowing a bit on how the framework works under the hood. The same way an android dev not only needs to know how 'generic' java works, but how android's java vm works.

3.- Those microservices may not follow a standard.

While frameworks allow you to write bad code, they kind of force you to follow some standards which reduce bad code and let other developers take on the project easily.

On the other side, a well developed microservice based project is usually better than an equivalent one that was based up on a framework. But it takes more time/work and has more risks (specially in php).

> It is very easy to write tiny secure code in PHP without a framework

Actually it isn't, like at all. A open source framework will always be more secure than the code you "easily write", because a larger pool developers can review,audit,test and fix that code.

Sure, the framework code will be more secure. But you still need to solve your problem and your framework isn't going to do it. So you have to write code.

The code you do write is going to be more secure if you know what's going on. If it's on top of a billion line framework, you might accidentally break the security without even realizing it. No legions of framework developers reviewed, audited, tested or fixed your actual code.

If you marry yourself to a single framework you remove a lot of degrees of freedom from PHP (which might be good or bad depending on the case) and introduce a set of rules that might or might not all be good for you.

It might save you time, initially. But at some point you will have to sit down and learn what the framework is actually doing behind the scenes (is it really secure? why is it so slow? I really need to implement this obscure, unsupported by my framework, thing), and you might not be so happy about your choice. Thinking about this ahead of time will save you headaches in the long run.

Think of PHP as sandbox programming. Such an open language, there is a lot of freedom, so many ways to achieve a specific result. The takeaway from the article is that "always do X" shouldn't be a thing, considering a) the vast possibilities and b) your purpose. Frameworks might be too much bloat, patterns should happen naturally, not forcefully. Security should be paramount, but it shouldn't be a blackbox behind third party code, you should be able to explain how you are protecting your users. Etc.

This is not a "don't use a framework/standards/etc" rant. I see it as a reminder to double-check if the current... trends/standards? match your actual needs and wants.

Being married to a framework is arguably worse than using separate, isolated and composable libraries to handle the equivalent things. You can fight architectural problems of a library easily, but not when there's one inside a framework and between its internal components.

I disagree. The odds of a grab-bag of small libraries by different designers who may or may not be actively maintaining them working well together is much smaller than the likelihood of a framework's components working together. And besides that, familiarity with the framework means you are able to understand its limitations and how to work around them.

Some frameworks are more composeable than others. Even some 'full-stack' ones like Symphony are becoming more component-ized

>Isn't a security one of the gains of using frameworks,

That depends on the scale of what you're building. Generally I would agree with you, but if you building some small, something that would only ever use a small subsection of whatever framework you pick, then you could end up having more issues than if you didn't use a framework.

Just because you aren't using parts of a framework, doesn't mean that security issues in the framework won't affect you.

Let's say your application only ever needs to do one or two queries to a database. It's going to be a whole lot easier for you to lock those two queries down, than securing an entire ORM.

> It's going to be a whole lot easier for you to lock those two queries down, than securing an entire ORM.

If it's a competent ORM then it shouldn't even expose any way to not use prepared statements, for example.

Most of security threats a small project encounters are very low-effort and concentrate around automatic checking for known exploits in widely used technology. Your site will be probed for known vulnerabilities a lot; but probability that somebody will actually invest his time in searching for SQL injections in your custom code is much lower.

"The very existence of PHP is a contradiction"

Uhm no for me coming from a C background I love PHP since its basically C with a lot of the boring/repetitive stuff abstracted away

Good PHP code exists, it only got a bad name due to "web developers" with no formal programming education stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes.

PHP is a hammer, blaming the hammer is silly when the person using it might now know how to swing it safely.

PHP is pretty objectively bad. For every thing PHP does decently well, something else does it better.

Except for this one weird trick: PHP absolutely bulls-eye nothing-but-net nailed deployability before deployability was even a word. In 2000, you could download an installer that set up Apache, MySQL and PHP on your Windows box (and it worked, first time and every time), you could fire up Notepad and 15 seconds later look at "Hello World" in your browser. Then you could upload that PHP file to a web hotel at $10/month and the world could see that same Hello World perhaps 10 minutes after that.

Heroku + Ruby on Rails gets close[1], but it took them nearly 10 years to catch up.

That's why PHP is so popular.

1: in zero-to-one deployability for a new user -- the full development and deployability experience just a tiny bit up the learning curve is orders of magnitude better.

There are more popular and worse languages, for example Javascript:

- no classes (so people end up emulating them: Backbone has methods to emulate class declaration and class inheritance)

- no type hinting. You cannot specify function argument type or return type. It makes code harder to read and to maintain.

- too forgiving. You can divide by zero or mistype a property name and get no error. You can add arrays to strings. It makes bugs harder to find.

- no coding standard. Everyone uses whatever style they like

- no single modules standard

- no syntax for asynchronous operations

- difficult to install XML library on Windows (you need to setup a Visual Studio to compile binary modules)

> Heroku + Ruby on Rails gets close[1], but it took them nearly 10 years to catch up.

You have to learn Linux and command line to use Ruby. No wonder it is more difficult for a newbie. Deploying and running an application is more complicated in Ruby. Also with long-living applications it is easy to get a memory leak.

But recently PHP started to depend more on CLI tools too (installing and using composer might be not easy for people who got used to GUI and don't understand concepts like "working directory").

FWWIW Ruby is my favourite language, but it's nowhere near being as beginner-friendly for web development as PHP. This is mostly because PHP was designed as an "embedded" language from the grounds up, and by the fact it's so widely supported by hosting providers. Most hosting providers have no support for Rails (or general rack-based applications); most that do, offer patchy support, though.

Furthermore, I remember a few years back, Ruby was a hassle to set up, especially on Windows.

Coming from a C background I used to hate PHP as it's inconsistent and flaky to the point of schizophrenia. Same applies to library naming. It positively encourages bad design and inconsistency. C wasn't and didn't.

Nearly all PHP I came across was the mess of some self-taught stumbling way beyond the point they should have been screaming for help, and going back to photoshopp. The docs don't exactly help here (may have changed, it's been a few years) as the apparently helpful comments on each feature aren't moderated in any way and are frequently unhelpful or plain wrong - but they're left to encourage the unwary.

I don't disagree it's perfectly possible to produce decent code with a good coder, and good principles applied to the project. I've seen some very clean looking PHP, and OO classes. That's been because they know the problems of the language and have been careful around such areas, or tried to avoid them entirely. I've worked on a couple of PHP based projects where I couldn't say a word against it as they'd used it well from the start.

We are where we are, but I would have been happier if the tool most often used by "web developers" stumbling in was a little more constrained and consistent about it.

> "web developers" with no formal programming education

I know developers who couldn't afford a "formal programming education" or couldn't/didn't go for various reasons, and they'd blow most "formally educated" developers out of the water. I think the word "formal" is surplus here.

> stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes.

This holds true for anything in life, really. Anyone who uses a tool which they don't understand will sooner or later make a mistake with that tool, and keep making mistakes.

WARNING: The next might be anecdotal, so YMMV. I used to write a lot of code in PHP (and I am grateful, because it is partially responsible for introducing me to the world of programming), but I slowly moved away from as time passed.

The main problems with PHP (apart from some interpreter issues/design decisions which I won't cover, because there's an abundant amount of that online already) are the fact that:

  1) it probably has the lowest entry barrier, with near-instant gratification and

  2) there is an insane amount of online tutorials, blog posts, courses and even "books" created by people who *think* they understand programming (and PHP), but actually don't.

Web development is not any more trivial than system development, or any less complicated. This probably goes for any type of development.

To be proficient in either, you need need to cover a very wide range of domains, but PHP resources makes you feel like web development is trivial and easy. Anyone who assumes web development is trivial doesn't really know shit about web development (excuse the language).

tl;dr: I mostly agree with you that PHP's design decisions aren't the only problem bad PHP code exists, and that people who use PHP are largely to be blamed for their own mistakes.

Of course I did not want to generalize and stereotype

Yes PHP makes it easy for ANYONE to stumble into scripting/programming

But IMHO that is a good thing, the world needs more people getting into programming, if they make mistakes so be it, learning from mistakes is a good way of learning anything.

> Good PHP code exists, it only got a bad name due to "web developers" with no formal programming education stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes.

It got a bad name due to the weird nature of PHP which is still a template engine , no matter how much features you had on top. It's like developing webapps in pure HAML, Jinja or Handlebars.

PHP also has a lot of bad design language wise, due to the incompetence of its creator and early maintainers when it comes to language design.

Replace "PHP" with "JavaScript" and you will have another true statement.

PHP "can be" used as a templating engine, but its not the right way to do it nor do you have to use it in that manner.

The correct way is to use Twig for your templates

PHP is alot more than a "templating engine" if thats all you think of it then that is your choice

Template engines are one of the more ridiculous inventions on the web, if you think of it. Doubly so if you have them in PHP, which is a perfectly good template engine - sure the syntax could be better, but the popular templating engines are even worse at any but most trivial tasks. They all start as an attempt to remove the possibility of writing meaningful code in them[0], and then grow cruft until they become Turing-complete due to the needs.

The more stupid thing about them, which transcends PHP and touches all other programming languages, is the very idea of assembling HTML piecemal from unstructured text. HTML is a textual representation of a tree, and should always be constructed as such - and not by gluing strings together. It's kind of the same problem as with SQL injections, which would not be possible in the first place if people weren't gluing them together from strings.

I'll probably get flamed for saying that, but really - many of the popular tools on the web are broken on a fundamental, conceptual level.

[0] - because of a misunderstanding of the "don't write logic in your views" principle; sure, don't write business logic in your views, but that doesn't mean you don't need, or shouldn't use, a real programming language in your views.

PHP actually is a bad templating engine for HTML because it doesn't have a feature to convert special characters to HTML entities by default. It is easy to forget a call to htmlspecialchars() (especially for beginners) so the code gets vulnerable to XSS.

That is why you should prefer Twig or other templating engine with autoescaping.

> They all start as an attempt to remove the possibility of writing meaningful code

I don't think so. Twig developers have a large list of reasons on their frontpage: http://twig.sensiolabs.org/

Not much difference:

    <?= escape($var) ?>
    {{ var | escape }}

Nevertheless, I used DOM/libxml on the server side in PHP/C, since 10 years ago, and was happy about it. It avoids all the other the template issues (balancing open/close tags, etc.) very well.

A few helper functions and you're good to go, with simplicity, flexibility and speed you will not get from any templating library in PHP.

Though, some coding customers don't know what to make of it. Some people have trouble with not being able to see HTML in the code, because "where do I paste my Google Analytics code?".

Twig does not require you to write escape so you can have to write just

    {{ var }}

That is a big difference because beginners always forget about escaping.

> Nevertheless, I used DOM/libxml on the server side in PHP/C,

There used to be XSLT templates but they don't seem to be popular now. Constructing DOM trees in the code without using templates is probably inconvinient and produces bloated code.

Not that much bloated. And it can be quite readable if done well. You also don't need to learn peculiarities of for loops or macro language in a given templating system. The host language is it's own macro language with all the features you already know, and not limited to whatever template language authors decided to implement.

Beginners also forget about balancing HTML tags, which is quite unpleasant experience when creating and changing more complicated templates with loops, conditions, etc. You can also do post-processing on the constructed DOM, even during construction.

Bloated code only happens if the programmer fails to structure the code into nicely re-usable functions. Anyway, it seems to be quite popular right now with all the react hype - React.createElement is such a helper function to help construct DOM tree.

It's pretty much the same concept on the server side. Except you don't need to care about DOM diffing, because server has no persistent DOM.

Couldn't agree more.

I've had decent success using an xml-object based approach, so certain structured parts of the template (navigation, form controls, etc) are built programmatically using dom methods and then serialised into the template.

PHP (the interpreter) used to be filled with bugs, design flaws and incoherences. It got better lately, but IMO it still caries a huge mess of legacy stuff that shouldn't even exist (mysql_real_escape_string anyone?)

In this case, both the hammer and the hammer's user can be blamed.

PHP7 has removed a lot of the old cruft and made some small improvements to PHP's idiomatic syntax.

One great example is the removal of the mysql_real_escape_string function. http://php.net/manual/en/function.mysql-real-escape-string.p...

Another is finally giving us a null coalescing operator, which is a solution for a constant pain point in dealing with raw PHP POST and GET parameters.

The full "new features" list of PHP7: http://php.net/manual/en/migration70.new-features.php

The change log of PHP7+: http://php.net/ChangeLog-7.php

They removed mysql_real_escape_string function so that you can use mysqli_real_escape_string http://php.net/manual/en/mysqli.real-escape-string.php

No, you use PDO::quote().

No, you use

  $pdo->prepare("SELECT id FROM foo WHERE bar = ? AND baz = ?")
      ->execute([$baz, $qux]);

...while taking care to set PDO::ATTR_MODE to PDO::ERRMODE_EXCEPTION and PDO::ATTR_EMULATE_PREPARES to false when your PDO object is initialized.

https://github.com/paragonie/airship/blob/8b7edde11b5b57fcb4...

See also: http://stackoverflow.com/a/12118602/2224584

This is the problem I have with PHP. 15 ways to do something seemingly simple, and only one obscure way is correct (What's PDO::ATTR_MODE ?) And why does PDO try to emulate prepares ?

That was 4 ways. The documentation identify what the options do.

Named parameters are much simpler to use IMO.

Simpler? No. Easier? Yes.

> coming from a C background I love PHP since its basically C with a lot of the boring/repetitive stuff abstracted away

It has a C-style syntax, but similarities almost completely stop there. Especially in modern OO PHP.

thanks!

You don't have to be a security expert in general, but you should aim to be one in the language you use, or do you intend to blame the framework everytime the shit hits the fan?