There is no doubt that getting in and out of a Laravel project is a bit more difficult than the example you suggest. But the example you suggest absolutely encourages bad practice.
I wrote that example, which is simplified, but here are some security things to keep in mind when dealing with PHP/MySQL:
- Always use PDO prepared statements to avoid SQL injections
- Should probably implement a CSRF token check
- You shouldn't output values directly from the user/database and that can lead to XSS
attacks (either sanitize the stored data, or when outputting it make sure the page is always interpreted as plain text)
- You might forget to check for permissions in a specific route (code enforce this via some linting/IDE rules, by using some automated tests or by checking in an included shared script that permissions were indeed verified)
Thank you. Somehow, I thought the tree structure they described for breaking down program logic was the problem. Obviously I agree with all the other stuff, which is table stakes for a safe web app
Always use PDO prepared statements to avoid SQL injections?
Sanitize your data and use whatever driver you want. Prepare statements are like sending xml instead of json. If you are populating a database with known data why add the overhead?
Bad practice, as in security-wise, performance-wise, readability-wise, or something else?
If you trust the developer to implement things properly (use PDO prepared statements when storing data in DB, properly check for permissions, write efficient queries, etc.), shouldn't that automatically exclude common bad practices?
If the developer is inexperienced, can't they still implement something in a bad way in Laravel (e.g. save a user-submitted file on the disk without checking for permissions)?
> If you trust the developer to implement things properly (use PDO prepared statements when storing data in DB, properly check for permissions, write efficient queries, etc.), shouldn't that automatically exclude common bad practices?
That depends. How tired is the developer? How under pressure? How over deadline? ;-)
I do get your point and I understand where you're coming from.
But this model of PHP (where every URL entry point is its own script) is the thing that most encourages expedient development rather than good development, because you can just hack on that one thing without affecting anything else.
It also (traditionally) encourages somewhat riskier hosting configurations, because any PHP file the web server can route may need to be executable, and because a failure of web server configuration can expose PHP files as readable. Whereas with a single point of entry (index.php router), you can locate your codebase outside the document root, refuse to directly execute anything but your endpoint script, etc.
These are partly old-fashioned concerns, admittedly, but it's surprising how often the approach you're outlining is still the source of malicious PHP exploits where a script file gets buried in a hacked release, or where some server vulnerability can be inveigled into executing PHP code by some image file upload mechanism that didn't do adequate checking.
I agree that writing secure PHP code is hard, but using a framework like Laravel, even if it has a single point of entry, makes it a lot more likely to introduce more security issues. When a framework is popular and open-source, people will spend a lot more resources trying to find and exploit vulnerabilities than in a custom private codebase: https://snyk.io/vuln/composer:laravel%2Fframework
But at the same time, I have never seen a project built along the lines you discussed that has not collapsed under the pressure for expedience, and it's just as vulnerable to issues in libraries (which any project of any complexity will use).
I think the biggest question to ask is how big the project is.
Wikipedia, Facebook, Etsy and other huge platform are written in PHP, but I doubt they use a framework like Laravel and not some in-house built platform.
Very tiny projects probably need no framework.
That leaves medium-sized projects, but again, it's hard to define what "size" means. I think a project is bigger if it implements various functionalities instead of having hundreds of different files that do a similar thing.
I can see Laravel being used more by out-sourcing companies. Custom frameworks or no framework being used more by companies building their own product.
