6 ms·

I just skimmed the website, and I am still not sure if it's meant seriously or if it's some kind of joke? Feels a bit contradictory eg. "dont use framework" vs

I just skimmed the website, and I am still not sure if it's meant seriously or if it's some kind of joke? Feels a bit contradictory eg. "dont use framework" vs "make software secure by default". Isn't a security one of the gains of using frameworks, beside other things? You would need to be a security expert to cover all potential security issues when writing something from a scratch.

bad_user 10y ago
The very existence of PHP is a contradiction, so I wouldn't sweat to much about it. But speaking of boolean logic, negating "always use a framework" does not yield your interpretation.
- throwaway1974 10y ago
  "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.
  - jlis 10y ago
    thanks!
  - roblabla 10y ago
    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.
    - Shanea93 10y ago
      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.php 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 http://php.net/manual/en/migration70.new-features.php The change log of PHP7+: http://php.net/ChangeLog-7.php http://php.net/ChangeLog-7.php
      - iopq 10y ago
        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 http://php.net/manual/en/mysqli.real-escape-string.php
        greyman 10y ago
        No, you use PDO::quote().
        CiPHPerCoder 10y ago
        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/8b7edde11b5b57fcb4b46024ca2227fd3cd4fc28/src/Engine/Database.php#L40-L47 https://github.com/paragonie/airship/blob/8b7edde11b5b57fcb4... See also: http://stackoverflow.com/a/12118602/2224584 http://stackoverflow.com/a/12118602/2224584
        roblabla 10y ago
        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 ?
  - spriggan3 10y ago
    > 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.
    - throwaway1974 10y ago
      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
      - TeMPOraL 10y ago
        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.
        10y ago
  - mseebach 10y ago
    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.
    - spoiler 10y ago
      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.
    - codedokode 10y ago
      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").
  - spoiler 10y ago
    > "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.
    - throwaway1974 10y ago
      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.
  - anexprogrammer 10y ago
    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.
  - mikegerwitz 10y ago
    > 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.
evook 10y ago
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?
pvdebbe 10y ago
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.
- emodendroket 10y ago
  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.
- paulryanrogers 10y ago
  Some frameworks are more composeable than others. Even some 'full-stack' ones like Symphony are becoming more component-ized
RyanZAG 10y ago
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.
- sametmax 10y ago
  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.
  - pc86 10y ago
    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.
    - sametmax 10y ago
      There is no such things as a "general purpose" framework anyone would use for such a small script. This would make no sense.
      - PolCPP 10y ago
arien 10y ago
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.
mrweasel 10y ago
>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.
- Nullabillity 10y ago
  > 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.
robert_tweed 10y ago
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.
- tclancy 10y ago
  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?
  - robert_tweed 10y ago
    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.
golergka 10y ago
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.

bad_user 10y ago

The very existence of PHP is a contradiction, so I wouldn't sweat to much about it. But speaking of boolean logic, negating "always use a framework" does not yield your interpretation.

throwaway1974 10y ago
"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.
- jlis 10y ago
  thanks!
- roblabla 10y ago
  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.
  - Shanea93 10y ago
    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.php 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 http://php.net/manual/en/migration70.new-features.php The change log of PHP7+: http://php.net/ChangeLog-7.php http://php.net/ChangeLog-7.php
    - iopq 10y ago
      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 http://php.net/manual/en/mysqli.real-escape-string.php
      - greyman 10y ago
        No, you use PDO::quote().
        CiPHPerCoder 10y ago
        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/8b7edde11b5b57fcb4b46024ca2227fd3cd4fc28/src/Engine/Database.php#L40-L47 https://github.com/paragonie/airship/blob/8b7edde11b5b57fcb4... See also: http://stackoverflow.com/a/12118602/2224584 http://stackoverflow.com/a/12118602/2224584
        roblabla 10y ago
        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 ?
- spriggan3 10y ago
  > 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.
  - throwaway1974 10y ago
    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
    - TeMPOraL 10y ago
      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.
      - 10y ago
- mseebach 10y ago
  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.
  - spoiler 10y ago
    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.
  - codedokode 10y ago
    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").
- spoiler 10y ago
  > "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.
  - throwaway1974 10y ago
    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.
- anexprogrammer 10y ago
  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.
- mikegerwitz 10y ago
  > 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.

evook 10y ago

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?

pvdebbe 10y ago

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.

emodendroket 10y ago
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.
paulryanrogers 10y ago
Some frameworks are more composeable than others. Even some 'full-stack' ones like Symphony are becoming more component-ized

RyanZAG 10y ago

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.

sametmax 10y ago
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.
- pc86 10y ago
  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.
  - sametmax 10y ago
    There is no such things as a "general purpose" framework anyone would use for such a small script. This would make no sense.
    - PolCPP 10y ago

arien 10y ago

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.

mrweasel 10y ago

>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.

Nullabillity 10y ago
> 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.

robert_tweed 10y ago

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.

tclancy 10y ago
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?
- robert_tweed 10y ago
  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.

golergka 10y ago

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.