The other side of the coin is whether you do a full security audit of every framework and dependency graph before you use it? When you write your own code you know there is nothing hidden.

That's a highly simplistic and incorrect way of looking at it. Do you know what CSRF is? Do you want to implement it every time you create a website? And all the other XSS vulnerabilities that could occur because you weren't careful.

Frameworks are much better at handling most security needs.

Most of the higher level code like that is written by incompetent people who make amateur hour mistakes and only release overengineered under documented slow broken code that is never supported and gets deprecated in a week.

I'm constantly shocked and amazed at the beginner mistakes riddled throughout these hip cool kid frameworks. And the dependencies of that code, and their dependencies, and the build system, and the management of the build system. It's a 5,000 hour a week job fixing all that and someone else will just go in and break it again.

So no, don't tell me to stop my life and fix everyone's mistakes. This is why there's 10 person teams to build an ecommerce site these days. This used to be a weekend project before all these slick stylish tools took up everyone's time.

Most people are incompetent and the more complexity you have, the greater your chances of getting crap code tearing your system apart

Why would I use something as a core piece of infrastructure written by people I'd never even consider hiring in a million years?

All too often you're standing on the shoulders of people tripping over their own shoelaces.

No thank you.

>>There are reasons people use frameworks. Security is one of them - I _love_ assessing apps which are written in plain PHP because they're almost always a trainwreck.

It’s totally OK for a prototype to be a trainwreck because its purpose is to give you the ability to launch it in front of potential users, show them a few features and get their feedback.

If it is open to the public, your train wreck cannot be open to common vulnerabilities like sql injection. Full stop. You can avoid unit or integration tests, not complete features, or cut any corner you want aside from basic security.

Don't presume anyone writing PHP is a trainwreck. With PHP7+ you can write modern applications that are perfectly secure, as much as anything you'd write with any other scripting language.

> Don't presume anyone writing PHP is a trainwreck.

I'm unsure anyone here is disputing this - my original comment said as much:

> Can you write secure code in PHP? Absolutely. But it's more effort and easier to get wrong.

It's undeniably more work to get right, though. As an example, if I create a new django app "the CSRF middleware is activated by default in the MIDDLEWARE setting" - you're safe by default.

I mean, even as a basic DiD measure PHP could use SameSite cookies by default for its sessions - but does it?

Sure it can. Almost every website on the internet right now has undiscovered security holes. Obviously you won't be leaving them open on purpose, but not using a framework is a legit choice and "it provides security that you can't implement without one" is a bad argument.

Yes there's convenience in "somebody already thought about everything you need before you did" but there are also security libraries, checklists, tutorials, and other tools besides a full framework with all its baggage to help developers write secure code.

I'm not saying anything either way on frameworks. But SQL injection is into to web development stuff. You can worry about cross site scripting or other security stuff later for a PoC,but not SQL injection.