I'd argue about the catchy headline...
This article is mostly about misconfiguration of a tool that is not PHP. It's like saying food is dangerous because one might suffocate eating it.
Just another article that spreads bad mood about a language that drives the majority of the web today.
PHP is just a tool and as with most tools, shitty users of the tool will produce shitty results.
The headline isn't much to argue about. The articles in this series often references a Christmas song or something along those lines. Sometimes I just can't figure one out, but this one is just "It's the most wonderful time of the year". I don't actually think PHP is particular insecure. It's just as unsecure as most others, and it is just as you say a tool for the user to do with as they will. They can use it terribly wrong, or just about right. This article dealt with a minor detail that some may get wrong. Having 24 articles on this series has meant that I've kept these incredibly tight.
And in closing, this is not to spread bad mood around PHP. This entire article series is about the opposite. I like PHP, and too many articles are written about its bad sides.
Forgive me, but I've read a ton of articles about how bad PHP is. Many of them by authors who used PHP for their personal page project back in summer 2000. The article gave me an impression of being one of those. I read "The most insecure code" ... and the open it ... and PHP comes out.
The title is catchy and simply misleading. I dislike that in any form of jurnalism.
The article itself does give a view on a security apsect related to PHP though, for which I am thankful. It's always good to educate about security flaws.
Yeah, you're not alone in that. Despite the very catchy title, it was just a mishap of me trying to tie it in with the theme of this article series that I'm writing. I appreciate you reading the article through and I'm going to make sure to keep a more balanced title in my other articles.
As a lover and user of PHP, I was driven to read this post due to the caption, but of course, it's rather misguided.
PHP is all about the configuration and coding orientation. As with other languages, when not properly used, can expose your codes to some security breaches. However, that does not make PHP bad in itself.
As you said, shitty users of every tool will produce shitty results.
I wrote it in a comment to someone else, but let's rehash this: I don't think PHP is any more insecure than any other language. In fact, if that was my argument I have made a pretty poor proof of it. I'm pretty sure I wrote this in the short article itself, but it's obvious I didn't make this point clear enough.
PHP is a great language. This article is the 19th article in this series, and nowhere am I claiming the language to be bad. It's up to how we use it! Now, what would have made any one think that I think this language is bad? Could it be the title? 🙃
Again, it's the code that's insecure. Not the language. So let's follow best practices to keep our insecurities to a minimum. I have benefitted greatly by following Symfony when I started coding PHP, but it's easy to just code and implement features and not keeping security in the front. So leaning against a handrail to guide us right is good. But again, that's not what this shift article was about. But I welcome anyone to discuss best practices.
Yes and no.
The article does mention things that are not handled on any respect by PHP (eg csrf, xss).
But PHP does have a mixed responsibility legacy.
In just about any other language, you have a clear separation between the platform whose job is to execute code written in the language.
It's often clear cut. Compiled languages are executed by the is (or some VM). Or some runtime.
PHP is a different story in that it needs at least the interpreter (to execute via CLI) but generally you need a webserver or fastcgi proxy that can interact with the platform (fpm or module that interacts with interpreter).
Each moving part has its own security issues and challenges and building a secure PHP execution chain requires knowledge in all of them.
Writing secure code in PHP is only a part of the issue, much less so than with other languages.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'd argue about the catchy headline...
This article is mostly about misconfiguration of a tool that is not PHP. It's like saying food is dangerous because one might suffocate eating it.
Just another article that spreads bad mood about a language that drives the majority of the web today.
PHP is just a tool and as with most tools, shitty users of the tool will produce shitty results.
The headline isn't much to argue about. The articles in this series often references a Christmas song or something along those lines. Sometimes I just can't figure one out, but this one is just "It's the most wonderful time of the year". I don't actually think PHP is particular insecure. It's just as unsecure as most others, and it is just as you say a tool for the user to do with as they will. They can use it terribly wrong, or just about right. This article dealt with a minor detail that some may get wrong. Having 24 articles on this series has meant that I've kept these incredibly tight.
And in closing, this is not to spread bad mood around PHP. This entire article series is about the opposite. I like PHP, and too many articles are written about its bad sides.
Forgive me, but I've read a ton of articles about how bad PHP is. Many of them by authors who used PHP for their personal page project back in summer 2000. The article gave me an impression of being one of those. I read "The most insecure code" ... and the open it ... and PHP comes out.
The title is catchy and simply misleading. I dislike that in any form of jurnalism.
The article itself does give a view on a security apsect related to PHP though, for which I am thankful. It's always good to educate about security flaws.
Yeah, you're not alone in that. Despite the very catchy title, it was just a mishap of me trying to tie it in with the theme of this article series that I'm writing. I appreciate you reading the article through and I'm going to make sure to keep a more balanced title in my other articles.
I agree with you.
As a lover and user of PHP, I was driven to read this post due to the caption, but of course, it's rather misguided.
PHP is all about the configuration and coding orientation. As with other languages, when not properly used, can expose your codes to some security breaches. However, that does not make PHP bad in itself.
As you said, shitty users of every tool will produce shitty results.
I wrote it in a comment to someone else, but let's rehash this: I don't think PHP is any more insecure than any other language. In fact, if that was my argument I have made a pretty poor proof of it. I'm pretty sure I wrote this in the short article itself, but it's obvious I didn't make this point clear enough.
PHP is a great language. This article is the 19th article in this series, and nowhere am I claiming the language to be bad. It's up to how we use it! Now, what would have made any one think that I think this language is bad? Could it be the title? 🙃
Again, it's the code that's insecure. Not the language. So let's follow best practices to keep our insecurities to a minimum. I have benefitted greatly by following Symfony when I started coding PHP, but it's easy to just code and implement features and not keeping security in the front. So leaning against a handrail to guide us right is good. But again, that's not what this shift article was about. But I welcome anyone to discuss best practices.
Thanks for the clarification.
Yes and no.
The article does mention things that are not handled on any respect by PHP (eg csrf, xss).
But PHP does have a mixed responsibility legacy.
In just about any other language, you have a clear separation between the platform whose job is to execute code written in the language.
It's often clear cut. Compiled languages are executed by the is (or some VM). Or some runtime.
PHP is a different story in that it needs at least the interpreter (to execute via CLI) but generally you need a webserver or fastcgi proxy that can interact with the platform (fpm or module that interacts with interpreter).
Each moving part has its own security issues and challenges and building a secure PHP execution chain requires knowledge in all of them.
Writing secure code in PHP is only a part of the issue, much less so than with other languages.