One Security Checklist for WordPress, Django and Strapi Sites

A website security checklist for an organisation running WordPress, Django and Strapi side by side should cover the same seven areas on every stack: identity and admin access, secrets and configuration, updates, API exposure, data, monitoring and recovery. The controls differ in name and location on each platform, but the questions are identical. Using one checklist, with a column per stack, makes gaps visible and stops each team from inventing its own standard.

Why mixed stacks need one checklist

Many organisations end up with more than one platform for good reasons. Marketing runs the corporate site on WordPress, a product team builds a portal on Django, and a mobile app pulls content from Strapi. Each team secures its own system in its own way, and nobody can say whether the organisation as a whole meets a single standard.

A shared website security checklist fixes that. It gives leadership one view, lets auditors ask the same questions everywhere, and makes it obvious when one platform lags behind. If you are still choosing between platforms for content, our comparison of WordPress and Strapi for multi channel content covers the trade offs.

How each platform is shaped

• WordPress is a full CMS with an admin dashboard, a theme layer and a large plugin ecosystem. Most risk comes from plugins, admin accounts and hosting.
• Django is a Python web framework. Security depends heavily on how the application is configured and coded, with strong defaults when they are used properly.
• Strapi is a headless CMS. It exposes content through APIs, so most risk comes from API permissions, tokens and the admin panel.

The cross platform website security checklist

The table below compares the main controls side by side. Use it as the master list, then add the detail each team needs.

WordPress: the controls that matter most

On WordPress, the biggest risks sit in plugins and admin accounts rather than in core. The official WordPress hardening guide recommends keeping core and plugins up to date, enabling two step authentication and disabling dashboard file editing with the DISALLOW_FILE_EDIT constant.

• Keep the number of Administrators small and review roles quarterly. Editors on a single site can post unfiltered HTML, so treat that role as powerful.
• Remove unused plugins and themes, and buy premium ones only from the vendor.
• Disable XML-RPC if nothing uses it, and restrict application passwords to integrations that need them.
• Block PHP execution in the uploads folder at server level.
• Run a web application firewall and rate limit login attempts.

For a fuller treatment, see our WordPress security hardening baseline and the people side in WordPress admin roles, approvals and MFA.

Django security: configuration is the control

Django security starts with production settings. The Django deployment checklist says DEBUG must never be enabled in production, SECRET_KEY must be kept out of source control, ALLOWED_HOSTS must be set, and the CSRF and session cookies should be marked secure once the site runs on HTTPS. It also recommends running manage.py check with the deploy option against production settings, which automates many of these checks.

Beyond the settings file

• Use the framework's protections. Keep CSRF middleware on, use the ORM or parameterised queries, and let templates escape output by default. Every exception should be deliberate and reviewed.
• Protect the Django admin. Limit superusers, restrict the admin route by network or single sign on where possible, and add MFA.
• Replace the development server. Production should run on a proper WSGI or ASGI server behind a web server or load balancer.
• Pin and scan dependencies. Python packages carry their own vulnerabilities; review them on a schedule, not only when something breaks.
• Check authorisation in code. Make sure every view that returns private data checks that the user is allowed to see that specific record.

Strapi security: permissions and tokens

Because Strapi serves content through APIs, Strapi security is mostly about who can call what. According to the Strapi Users and Permissions documentation, any request without a token takes the Public role's permissions, and users who register through the standard route receive the Authenticated role. Public sign ups can be switched off in the advanced settings.

Strapi checklist

• Audit the Public role. Grant only the find and findOne actions on content that is meant to be public. Never allow create, update or delete for unauthenticated requests unless there is a reviewed reason.
• Disable registration if the project does not need end user accounts.
• Scope API tokens. Strapi offers read only, full access and custom tokens with a choice of duration. Prefer read only or custom tokens, set an expiry, and keep full access tokens for trusted server side jobs only.
• Keep tokens server side. A token placed in a browser or mobile app bundle can be extracted, so treat any client side token as public.
• Protect the admin panel. Limit admin users, use admin roles to separate editors from administrators, and restrict access to the admin route by network or single sign on where possible.
• Review JWT settings. Keep session lifetimes short and secrets strong, following the current Strapi documentation for your version.

Shared controls every stack needs

Admin access security across platforms

Admin access security should follow one policy regardless of platform: named accounts only, the smallest role that fits the job, MFA for anyone who can publish or configure, and access removed on the day someone leaves. Connecting all three admin areas to one identity provider makes this far easier to enforce, because one switch removes a leaver everywhere.

Hosting, network and transport

• HTTPS everywhere, with secure cookies and modern TLS configuration.
• Separate environments for development, staging and production, with production data kept out of development.
• Admin routes restricted where practical, by IP allow list, VPN or single sign on.
• A web application firewall or CDN in front of public sites.

Data protection

List what personal data each platform holds, where it is stored and who can export it. Forms on WordPress, user tables in Django and collections in Strapi all count. Organisations processing personal data in the UAE should check which regime applies, whether the UAE PDPL (Federal Decree-Law No. 45 of 2021), the DIFC Data Protection Law or ADGM rules, and confirm obligations with legal counsel.

Monitoring, backups and recovery

• Centralise logs from all three stacks so suspicious activity can be compared across them.
• Alert on admin logins, role changes, new tokens and configuration changes.
• Back up databases and uploaded files off the server, and test a restore on a schedule.
• Keep one incident response plan that names owners for each platform. Our WordPress cleanup and incident response playbook shows the stages, and they translate to the other stacks.

Turning the checklist into a routine

1. Assign an owner per platform and one person accountable for the checklist overall.
2. Score each control as in place, partly in place or missing, per platform.
3. Fix the highest risk gaps first: exposed debug output, public write permissions, shared admin accounts and missing MFA.
4. Review quarterly and after every major release, new integration or staff change.
5. Keep evidence: screenshots, configuration exports and review notes, so audits do not start from scratch.

Hypothetical example: an Abu Dhabi education provider runs its marketing site on WordPress, a student portal on Django and a mobile app fed by Strapi. Its first review finds three Administrators who have left on WordPress, a Strapi Public role allowing content creation, and DEBUG still on in the portal's staging environment, which is reachable from the internet. None of these would have shown up if each team had only checked its own list.

If you are planning a new build, our guide to what a good custom WordPress build includes shows where security fits into the project from day one.

Bring all your platforms up to one standard

Codeeo's services cover the work this checklist touches: WordPress development, custom software and business systems, and headless ecommerce built on API driven content. A website audit is a practical place to start if you want a single view across platforms. With 200+ projects delivered across the UAE and the US and an office in Dubai, our team can review your set up with you in person. Contact us to talk it through.