SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
When we talk about security,
what do we really mean?
• You have sites
• They have intended purposes
• We want them to focus on those purposes and not be co-opted for other
• Preventing this co-opting of your sites is the starting point of security
What are we securing against?
• Physical intrusion
• Code vulnerabilities
• Server (stack), application, customization
• Vulnerabilities (XSS, SQLi, escalations)
• Bad actors
• Human and not so human
Why aren’t we talking about physical security?
• Very few of us are managing/running our own datacenter(s)
• Physical security is almost always out of your direct control
• Any reputable hosting solution will have this covered for you
Keeping Trusted Packages Secure
• Be aware of security releases for important stack software, plugins,
• mailing lists, alerts, regular update checks, etc.
• Have a regular update schedule, or use automated updates
• Use checksums/trusted package managers when applicable!
• Be vigilant - security patches happen for a reason
WordCamp US 2016 Presentation
What to Look For in Code Review
• Validation, sanitizing, escaping
• Cross-site scripting vulnerabilities
• Smart fetching of remote data
• Outright nasty code - did someone access code who shouldn’t have?
How to Do Code Review
• Refer to last year’s presentation
• Biggest recent improvement: code review on GitHub
• Protected branches
• Use continuous integration tools and tests!
• No-one merges their own changes?
• Single-dev is both more and less dangerous
Forced Login Protection
• Repeated attempts by bad actors to test logins to your site
• Several pre-packaged service solutions available to help with this
• Jetpack Protect
• Twice as many steps!
• Requires access to a physical device
• Lots of good solutions
• Jetpack/WordPress.com SSO
• Best to use an app, not SMS
• Remind users to have their backup codes!
Reducing Your Administrators
• Only give admin access to people who absolutely need it
• If there is a feature non-admins cannot access and want to:
• Do they really need it?
• Will it give them access to other things they should not have?
• Are they using two-step authentication?
• Consider experimenting with and using custom roles
Reducing the Damage Users Can Do
• Remember that admins can do EVERYTHING
• Consider custom code restricting or disabling some features:
• Code editors
• Site settings
• Load and activate plugins via code, not UI
• The default user system is great for a large number of WordPress sites,
but it might need some tweaking for your sites or projects
• Limit access to datastores as much as possible
• Limit access to any credentials you need to store as well
• Code review! Again!
• Observe best practices for local security for any local copy of your data
Backing Up Your Sites
• Database dumps
• sqldump + scripting
• Various backup plugins
• Backup installations
• Hosting provider backups
• What does your host provide?
• Using a “cloud” backup solution