4 ms·

All of these points are valid, none of them are unique to the Wordpress solution. If you're writing a reasonably complex CMS, you will create security flaws yo

All of these points are valid, none of them are unique to the Wordpress solution. If you're writing a reasonably complex CMS, you will create security flaws you can fly a 747 through. This is doubly true if the CMS isn't the end goal and rather a necessary dependency for what's actually needed. The only guard against security holes is battle-testing your code - Wordpress may not be the most secure thing in the world, but it's likely more secure than something you can whip up yourself in a jiffy. Ditto maintenance and obsolescence - in fact this problem is probably worse for a homebrew solution than WP, since the number of people qualified to maintain this homebrew codebase is approximately one, whereas you can actually hire for WP plugin maintainers if you need to. Likewise, homebrewing your own solution and then moving onto the next project literally means it's not being maintained from day one, which is strictly worse than even a casually maintained plugin. WP installs aren't always the right solution, nor is deploying some off the shelf code, but choosing to write your own code needs to pass a higher standard than is normally applied in most companies - it's silly to complain that some open source thing might stop being maintained when by default what you write yourself is also not actively maintained ;)

joshmanders 11y ago
I get your points, but at least with custom code you have security by obscurity. Using out of the box stuff puts you in a higher level of security risk because anyone can access the code and find bugs and how to exploit them. At least with custom code, it'll take some time for them to find something and attack you. I mean for crying out loud, just installing Wordpress invites people trying to get in using automated tools. You can deploy a wordpress blog at it's default state, and wake up 3 days later to it being spammed.
- snowwrestler 11y ago
  The bad guys generally don't bother browsing Wordpress code to find vulnerabilities. It's tiresome to do, especially since a lot of good guys are doing the same thing and patching the obvious bugs. Instead they use automated attacks to test any website directly for the most common errors. Understand that this is not limited to Wordpress. The types of vulnerabilities they test for are universal: password brute force, directory permissions, code injection, XSS, etc. Sometimes one of these tests works, a site gets hacked, and then the developer has to a) recognize the site has been hacked, b) diagnose the problem, c) patch the hole, and d) recover the site. For open-source projects like WordPress, the developer can then contribute the patch back to the community, and everyone else can pre-emptively fix their sites, even if they haven't been hacked yet. Bad guys also get these patches, and add automated attacks based on them. These are often what you see in WP logs, but such attacks are easily defeated by simply applying patches when they come out. For custom-developed sites, you the developer must do all those steps by yourself, and yes that means you probably won't know about vulnerabilities until they are exploited.
cthalupa 11y ago
> it's silly to complain that some open source thing might stop being maintained when by default what you write yourself is also not actively maintained ;) I certainly agree to a large extent, but there's a lot that mitigates this as well: When it's code you write, you have control over feature creep, documentation, comments, etc. If you write something that only does what you need, you reduce a lot of the attack surface vs. off the shelf plugins, and you are in a position to make sure that the code commented and well documented. You don't have that sort of quality control over a third party plugin, and you may down the line be in for a rude awakening when it's no longer developer and has a breaking problem, and you open it up and find the code is a completely undocumented mess from top to bottom. Of course if you're rushing something out the door, you might not produce anything better - but if you're a software shop with solid engineers, you have a high chance of being able to get better quality code out there than a lot of WP plugins. (That being said, WP today is a lot more secure itself than it was in the past - the right option might be not writing the CMS from scratch, but writing any plugins you need from scratch)

joshmanders 11y ago

I get your points, but at least with custom code you have security by obscurity. Using out of the box stuff puts you in a higher level of security risk because anyone can access the code and find bugs and how to exploit them. At least with custom code, it'll take some time for them to find something and attack you. I mean for crying out loud, just installing Wordpress invites people trying to get in using automated tools. You can deploy a wordpress blog at it's default state, and wake up 3 days later to it being spammed.

snowwrestler 11y ago
The bad guys generally don't bother browsing Wordpress code to find vulnerabilities. It's tiresome to do, especially since a lot of good guys are doing the same thing and patching the obvious bugs. Instead they use automated attacks to test any website directly for the most common errors. Understand that this is not limited to Wordpress. The types of vulnerabilities they test for are universal: password brute force, directory permissions, code injection, XSS, etc. Sometimes one of these tests works, a site gets hacked, and then the developer has to a) recognize the site has been hacked, b) diagnose the problem, c) patch the hole, and d) recover the site. For open-source projects like WordPress, the developer can then contribute the patch back to the community, and everyone else can pre-emptively fix their sites, even if they haven't been hacked yet. Bad guys also get these patches, and add automated attacks based on them. These are often what you see in WP logs, but such attacks are easily defeated by simply applying patches when they come out. For custom-developed sites, you the developer must do all those steps by yourself, and yes that means you probably won't know about vulnerabilities until they are exploited.

cthalupa 11y ago

> it's silly to complain that some open source thing might stop being maintained when by default what you write yourself is also not actively maintained ;) I certainly agree to a large extent, but there's a lot that mitigates this as well: When it's code you write, you have control over feature creep, documentation, comments, etc. If you write something that only does what you need, you reduce a lot of the attack surface vs. off the shelf plugins, and you are in a position to make sure that the code commented and well documented. You don't have that sort of quality control over a third party plugin, and you may down the line be in for a rude awakening when it's no longer developer and has a breaking problem, and you open it up and find the code is a completely undocumented mess from top to bottom. Of course if you're rushing something out the door, you might not produce anything better - but if you're a software shop with solid engineers, you have a high chance of being able to get better quality code out there than a lot of WP plugins. (That being said, WP today is a lot more secure itself than it was in the past - the right option might be not writing the CMS from scratch, but writing any plugins you need from scratch)