How Strapi security hardening starts with the public API surface
The starting point for Strapi security hardening is the public API surface: every content type, route and field that an unauthenticated or lightly authenticated caller can reach. A Strapi project that is moving toward production or being reviewed after launch should begin by listing what is exposed by default, then deciding what should remain open. Strapi's REST and GraphQL APIs are generated from content types, so the review is about what the project has already published, not only about the framework's own code. Most Strapi exposure does not come from the framework alone. It comes from five places: role permissions for the Public and Authenticated roles in the Users and Permissions plugin, the scope of each API token, who holds administrator access to the admin panel, environment configuration such as secrets and debug settings, and the dependency tree that the project installs and ships. Each of these is configured separately, so a review that checks only one of them will leave gaps in the others. The work is harder than it looks because these controls are spread across several places and interact. A permissive public role can expose content that a strict token scope was meant to protect, and an open CORS setting can let a browser reach an API that the permission model otherwise restricts. Because a single permissive setting can undo a strict one elsewhere, the reviewer should trace each path from request to response instead of checking settings in isolation. As a first action, export the current role permissions for Public and Authenticated, list every API token with its type and scope, and record which administrators can change roles or environment values. Then test the public endpoints without credentials and confirm each response is intended. Keep these claims tied to what the platform configuration controls, and confirm the exact settings, menu locations and defaults against the Strapi version the project runs, because Strapi 5 minor releases ship frequently and configuration details can change between them.
Which Strapi surfaces need a security review
A self-hosted Strapi project exposes risk through several surfaces at once: public API permissions, tokens, the admin panel, configuration secrets, browser access rules, request limits and third-party packages. Reviewing them together shows which settings interact, such as a public role that exposes what a token would otherwise have to grant.
Users and Permissions and public role
The Users and Permissions plugin controls end-user accounts and the public role that applies to anonymous REST and GraphQL requests. Check first which content types and actions the public role can reach, including find and findOne on collections that should stay private, and whether GraphQL exposes the same fields as REST. Confirm that registration and password reset settings match your intended user flow.
API tokens and their scope
API tokens authenticate machine clients such as front ends, build jobs and integrations, and each token carries its own permission set. Check which tokens exist, who owns them, whether they are read-only or full access, and when each was last rotated or used. Tokens created for one integration should not hold write or delete rights on content types that integration never touches.
Admin panel and administrator accounts
The admin panel is the highest-privilege surface, since an administrator can change roles, tokens, plugins and content types. Check how many super administrator accounts exist, whether the admin path is reachable from the internet or only from approved networks, and whether two-factor or SSO login is required. Ask your team to confirm which features in your plan cover SSO and audit trails before relying on them.
Environment variables and configuration files
Secrets such as the application keys, JWT and API token salts, database credentials and upload provider keys live in environment variables and configuration files. Check that none are committed to source control, that production values differ from development values, and that the admin and server settings read secrets from the environment rather than from literal strings. Confirm who can read the deployment environment.
CORS and proxy settings
CORS settings determine which browser origins can call the API, and proxy settings determine which client address Strapi trusts when it sees forwarded headers. Check that the allowed origins list contains only your front-end domains rather than a wildcard, and that the proxy configuration matches the actual load balancer or reverse proxy in front of the server. Misconfigured proxy trust can distort IP-based logic such as rate limits.
Rate limiting at the application or edge
Strapi does not guarantee that public endpoints are protected from abusive request volume, so limits must be set somewhere in the request path. Decide whether limits sit in the application layer, at the reverse proxy or at a CDN or web application firewall, and check that login, registration and token-protected endpoints are covered. Confirm the limits with load tests that reflect your real traffic.
Node.js and npm dependency tree
Strapi runs on Node.js and pulls a large npm dependency tree, so vulnerabilities can arrive through the framework, a plugin or a transitive package. Check that the Node.js version is on an Active or Maintenance LTS line supported for your Strapi version, that lockfiles are committed, and that an audit or software composition scan runs on each release. Confirm the Strapi version itself is still receiving updates before planning hardening work.
Decisions to make before changing the configuration
This table compares the six choices that shape a hardened self-hosted Strapi and the work each one adds. Read each row as a decision to settle with your security and content owners before changing roles, tokens or admin access. The main takeaway is that every tightening step trades exposure for a recurring operational task, so agree on the owner for each one before go-live.
| Decision | Option and when it fits | Operational cost |
|---|---|---|
| Public or authenticated reads | Public reads for published content only. Authenticated reads for drafts, internal or partner data. | Each public content type needs a field and filter review. Authenticated reads add token or JWT handling to the front end. |
| Token scope | Read-only tokens for front ends and scheduled jobs. Full-access tokens only for trusted administrative tasks. | One token per consumer means more secrets to rotate and track, but a leaked token reaches only one consumer. |
| Admin panel exposure | Public internet access suits distributed editors. Network-restricted access via VPN or a private path suits internal teams. | Restriction removes exposure to brute-force attempts but adds VPN support, access requests and editor friction. |
| Local administrator login | Keep a local login as break-glass access during SSO rollout. Lock it out once SSO is confirmed for every administrator. | Lockout risks losing all admin access if the identity provider fails. Keep a tested recovery path with a named owner. |
| Rate limiting location | In the application for simple single-instance deployments. At a reverse proxy or edge service when several instances need shared limits. | Application limits are versioned with the code but apply per instance. Edge limits live outside Strapi and need their own monitoring. |
| Audit logs | Needed when auditors or internal reviewers must see who changed content or roles. Otherwise, confirm what the hosting layer already records. | Audit logs are an Enterprise feature on the self-hosted pricing page. Confirm plan fit before design, not after. |
How to harden a Strapi project in sequence
This sequence takes a self-hosted Strapi project from default access to a reviewed baseline. Each step changes one control area, from content roles and API tokens to secrets, admin access, browser origins and runtime versions. Each step closes with a check that can be repeated in every environment.
Inventory content types and role access
List every content type, component and custom endpoint in the project, then record which Users and Permissions roles and API tokens can read, create, update or delete each one. The Strapi project owner and the security lead do this together, using the admin panel and the project's schema files as sources. Done means the team holds one table of content type, role and action, signed off by the content owner, which serves as the baseline for every later step.
Set public and authenticated roles to deny by default
Reset the Public and Authenticated roles so that no action is allowed, then enable only the find and findOne actions, or specific endpoints, that the front end needs. A developer makes the change in the admin panel and records the intended permission set in the project documentation. The check is an unauthenticated request to each protected collection, which should return the expected denial status, and a request to each intentionally open endpoint, which should return only the fields the front end uses.
Review custom routes and controllers for policies
Custom routes and controllers do not inherit the same review as generated ones, so each one needs an explicit authentication or policy setting. A developer reads every route file and controller under the API folders, lists any route without an auth configuration, and confirms each handler validates input and returns only the fields the consumer should see. Done means every custom route has a documented auth setting and a test showing that an unauthenticated call is refused wherever access should be restricted.
Create scoped API tokens for each consumer
Issue one API token per consumer, such as a build job, a front-end server or an import script, and grant each token only the actions it needs. A token used for reading public content should have no write permission. The check is to send a request outside a token's scope and confirm it fails, then create a test token, revoke it and confirm the revoked value no longer works. Record the owner and purpose of each token in the operations register.
Move secrets into environment variables
Move database credentials, app keys, the JWT secret and the API token salt out of configuration files and into environment variables supplied by the hosting platform or a secrets manager. The developer removes committed values from source control and rotates any value that was ever committed. Rotating app keys, the JWT secret or the token salt may invalidate existing sessions and tokens, so the team should test the impact in staging first. Done means the application starts from environment values alone and a search of the repository finds no live secret.
Restrict admin panel access by network path
Limit who can reach the admin panel by placing it behind a VPN, a private network, an allow list at the reverse proxy or an identity-aware gateway, depending on the environment. Then review every administrator account and its role, remove unused accounts and confirm each administrator holds the least role needed. If admin login uses SSO, confirm in the Strapi SSO documentation whether local login can be locked out. The check is a login request from an address outside the allowed range, which the proxy should refuse, and a signed administrator list from the owner.
Set CORS origins and rate limits at the edge
Replace any wildcard CORS setting with the exact front-end origins, including protocol and port, for each environment. Then add rate limits for the public API and login routes at the reverse proxy, CDN or application layer, and confirm the mechanism with the platform team before launch. The check is a request from an origin that is not on the list, which should receive no permissive CORS header, and a burst of requests above the limit, which should receive a throttled response. The limit values themselves should be set from the expected traffic profile.
Pin Node.js and database versions
Set the Node.js version explicitly in the build and runtime images so every environment runs the same release. Choose an Active or Maintenance LTS line that the Strapi version in use supports, and check the Strapi installation requirements before choosing. Also pin the database to a version listed as supported in those requirements, such as PostgreSQL 14 or later. The check is a clean install, build and start on the pinned versions, followed by a dependency audit whose findings the team has reviewed and recorded.
What drives the effort of a Strapi security review
This table lists the factors that change how much work a Strapi security review takes and how to keep each one manageable. Read the one-time and recurring column first, because recurring items such as token rotation and dependency review continue after the review ends. Effort depends on the written scope and on the actual codebase, so treat every row as a question to answer during scoping.
| Effort driver | Why it changes the work | How to reduce it | One-time or recurring |
|---|---|---|---|
| Content types and custom routes | Each content type and custom route needs its own role and permission check for public and authenticated access, and custom controllers need review for missing authorization. | Keep public content types few, remove unused routes, and document which routes are intentionally open. | One-time review, then recurring when new types or routes are added |
| Front ends and API consumers | Every front end, mobile app or service that calls Strapi needs a scoped API token or a permissions role, and each one adds a credential to review. | Consolidate consumers where possible and give each one the narrowest role that serves its reads and writes. | One-time setup, recurring when consumers change |
| Administrator roles and identity sources | More admin roles and more login paths, such as local accounts alongside an identity provider, widen the set of accounts to test and monitor. | Limit super admin accounts, define roles around tasks, and decide whether local login stays enabled once SSO is in place. | One-time review, recurring access reviews |
| Environments and secret movement | Development, staging and production each hold keys and config. How secrets reach each one, and whether production data is copied down, determines the scope of exposure checks. | Keep secrets out of source control, use separate keys per environment, and document how config is promoted between them. | One-time review, recurring on each deployment pipeline change |
| Custom and third-party plugins | Custom code runs with the same privileges as Strapi core, and third-party plugins add routes, admin pages and dependencies that each need review. | Remove unused plugins, prefer maintained packages, and keep custom plugins small and well tested. | One-time review, recurring when plugins are added or updated |
| Compliance evidence requirements | An assessor may ask for logs, access reviews, token inventories and change records. Each requested artifact adds collection and retention work. | Agree the evidence list in the written scope before work starts, and confirm which controls your auditor expects. | Mostly one-time setup, with recurring evidence collection |
| Dependency tree after the last upgrade | A project that has fallen behind on Strapi 5 minor releases, Node.js LTS changes or plugin updates carries more known-vulnerable packages to triage. | Upgrade to a current Strapi 5 release and a supported Node.js LTS version before the review, and confirm the patch cadence afterward. | One-time triage, then recurring dependency review and patching |
| Token rotation and credential lifecycle | Tokens and API keys need expiry, rotation and revocation procedures, and each rotation must be tested against every consumer. | Inventory tokens with their owners and scopes, set a rotation schedule, and automate updates where the deployment allows. | Recurring |
Controls that keep a Strapi API and admin panel locked down
A self-hosted Strapi instance exposes two surfaces: the content API that front ends and third parties call, and the admin panel that editors and developers use to change content and configuration. The controls below address who can call the API, who can reach the admin panel, where secrets live, and which systems the instance can touch. Confirm each setting against the Strapi version you run, because defaults and option names change between releases.
Deny-by-default API permissions and tokens
The Users and Permissions plugin and the API token settings decide what anonymous and authenticated callers can read or write. Start with the public role set to no access, then grant find or findOne only on content types that must be public, field by field where Strapi supports it. Review each API token for read, write or delete scope, and set an expiry for tokens used by build jobs. Confirm how your installed version names these permissions and whether token lifetimes are configurable.
Secrets outside the repository and logs
Strapi relies on values such as application keys, JWT and API token salts, and database credentials. Keep them in environment variables or a secrets manager, never in config files committed to version control. Check that CI pipelines mask these values and that deployment scripts do not echo them to build logs. Rotate any value that has ever been committed, and confirm the full list of required secrets in the configuration reference for your version.
Admin panel network restriction
The admin panel should not be open to the whole internet when the network allows a narrower path. Options include an allow list of IP ranges at the load balancer or web application firewall, access only through a VPN, or a zero-trust access proxy that authenticates each user before the request reaches Strapi. Keep the public API on a separate route if the same instance serves both. Confirm how your hosting platform handles admin path routing and health checks before you apply the restriction.
Administrator roles and unused accounts
Administrator access should follow the smallest set of roles that a person needs. Separate super administrators, who can change roles and install plugins, from content editors who only manage entries. Remove accounts for staff who have left and for former agency or contractor users, and review the list on a fixed schedule. If you use SSO for admin login, confirm the default role for auto-registered users and whether local login can be disabled, since SSO availability depends on your Strapi plan.
CORS, rate limits and GraphQL exposure
Restrict CORS to the exact origins of your front ends instead of allowing every origin. Apply rate limits to login, token issuance and write endpoints, which are the most common targets for credential guessing and abuse. In production, disable the GraphQL playground and review whether introspection is needed, since both reveal the schema to anyone who can reach the endpoint. Confirm the rate-limit and GraphQL options in the middleware and plugin documentation for your version, and test each setting with a request from an unlisted origin.
Patching and reachable data stores
Keep Strapi, its plugins and the Node.js runtime on supported releases, and review security advisories for them on a schedule that someone owns. Strapi 5 runs only on Active or Maintenance LTS Node.js versions, so an unsupported runtime is a hardening gap in itself. Limit the database account to the schema Strapi needs, and restrict upload storage so that the instance can write only to the bucket or directory it uses. Confirm supported database versions in the installation requirements before any change.
How to test that a hardened Strapi fails safely
The verification plan starts with an unauthenticated request matrix. List every route a visitor with no credentials can reach, both REST endpoints under the API prefix and, if the GraphQL plugin is installed, the GraphQL endpoint. Send each request without a token and record the status code, the response size and the fields returned. Compare each result with the role and permission review. Any successful response for content the design says is private is a finding. Test GraphQL as queries, not only as paths, because a single endpoint can return nested fields that no individual REST route exposes. Confirm whether introspection is enabled in production and whether the decision to keep it on was deliberate.
Token boundary tests come next. Create test API tokens for each scope the design defines, including read-only and any custom scope, then use each one against endpoints and actions outside its grant. Attempt creates, updates and deletes with a read-only token, and attempt reads on content types the token was never given. Also test expired and revoked tokens, and confirm that a token issued for staging is rejected by production. Run the same matrix with end-user tokens from the Users and Permissions plugin. Keep each test tied to a named expected result so a reviewer can see the rule being checked, not only the outcome.
Reachability and browser-facing tests come next. From a network outside the allowed path, such as the public internet or a segment that should not reach the admin panel, request the admin URL and confirm that the reverse proxy or firewall blocks it. Then send cross-origin requests from origins that are not on the allow list, including preflight requests, and check whether the Access-Control-Allow-Origin header reflects the attacker-supplied origin. Send rapid repeated requests to the login and token endpoints and confirm that the limit your proxy or application sets is reached and that the response is consistent. Record the threshold you tested so the result can be repeated later.
Error handling and secrets need their own checks. In staging, send malformed bodies, invalid IDs and oversized payloads, and confirm that responses carry no stack traces, file paths, query text or configuration values. Scan the Git repository and the built container images for committed secrets, and confirm that environment files are excluded from images. Run a dependency audit against the lockfile and record the tool version, the date and each finding with its disposition. Store the evidence in one place: the request matrix, raw responses, scanner output, configuration snapshots, tester name, pass or fail results, and a ticket for each fix with a retest. Independent security testing by a different party can be scoped and priced separately from configuration work, and it is worth asking for when the results will support a compliance review.
How hardening changes by deployment model
On a single node, Strapi, the database and the reverse proxy usually share one host, so most controls live in the application configuration and the operating system. Rate limiting may be handled by the reverse proxy or by middleware inside the Strapi application, and the team should decide which layer owns it. Admin panel exposure is often limited by network rules on the host itself, and one server means one place to patch the operating system, the Node.js runtime and Strapi dependencies.
- Environment files: keep the secrets file readable only by the service account, outside the web root and out of version control.
- Admin panel: restrict the admin path at the proxy or host firewall to the networks your access model allows.
- CORS and rate limits: set allowed origins in Strapi and enforce request limits at the proxy, then test that both respond as expected.
- Patching: schedule Node.js and Strapi dependency updates on the same host, with a database backup taken beforehand.
Check which layer owns each control on this host, because a single machine can hide overlaps and gaps between the proxy and the application.
With several instances behind a load balancer and an external database, the application nodes should hold no state that matters. Secrets, uploads and any shared configuration move to shared services, so every instance must read identical settings. Rate limiting often sits at the load balancer or a web application firewall, because counters kept on one instance would not reflect total traffic. Admin access may be restricted through listener or path rules on the load balancer.
- Rate limiting: decide whether limits live at the load balancer, a web application firewall or the application, and test that client IP headers reach Strapi correctly.
- Secrets: inject database credentials and application keys from a secret manager at startup, not from files copied to each node.
- Database access: allow connections only from the application subnet and use encrypted connections where the database platform supports them.
- Trusted proxy settings: configure proxy header trust so that IP-based controls see the client address and not the load balancer address.
Confirm the load balancer's header handling and the secret manager's access policy with your platform team before you rely on either control.
On a container platform, many hardening decisions move into cluster objects. The ingress controller often handles TLS, host routing and restrictions on the admin path, while network policies control which pods can reach the database and other services. Secrets usually come from the cluster secret store or an external secret operator, and the dependency patch cycle runs through image builds rather than through changes on individual servers.
- Admin access: use ingress rules or an authenticated gateway to limit the admin path, and confirm that the rule covers every route that serves the admin panel.
- Network policies: allow only the Strapi pods to reach the database and the upload provider, and deny other traffic by default where the cluster supports it.
- Secrets: mount secrets through the platform's secret mechanism, and check that they are not written into the image or into chart values in plain text.
- Image patching: rebuild images when Node.js or Strapi dependencies change, and scan them in the registry before promotion.
Confirm which ingress controller, network policy engine and secret operator your cluster runs, because the exact behavior of each control depends on those components.
In air-gapped or restricted networks, the server cannot fetch packages, licenses or external services at runtime. Dependency patching depends on an internal package mirror and a controlled transfer process, and the team must confirm that the mirror holds the exact Node.js and npm packages the build requires. Outbound calls for updates, telemetry or third-party services should be disabled or verified, and every control must be tested inside the restricted network because results from a connected test system may not carry over.
- Package mirror: host the Node.js runtime, npm packages and container base images in an internal mirror, and record which versions were approved and when.
- Outbound traffic: list every outbound call the application makes at startup and during normal operation, and block those that are not needed.
- Secrets: use the restricted network's approved secret store or sealed files, with rotation procedures that do not depend on internet access.
- Update path: define how approved patches cross the boundary, who reviews them and how a rollback would be performed.
Verify the mirror contents and the outbound block list on the restricted network itself before accepting the build.
What to monitor, rotate and document after launch
Hardening only holds if someone keeps checking it after launch. The configuration you signed off will drift as the team adds content types, custom controllers and public endpoints, and each addition can open access that nobody reviewed. Make a permission review a standing step in the development workflow. Every new content type or custom route should have its public and authenticated role settings checked before release, and the reviewer should confirm that find and findOne are granted only where a front end needs them. Agree who signs off, and record the date and reviewer in the change ticket. This review is quick to run on each change and slow to reconstruct after an exposure, so decide early who owns it.
Start with an inventory of every API token and administrator account. For each API token, record its name, its type (read-only, full access or custom), the content it can reach, the system that holds it and the person accountable for it. Tokens created for a test and never removed are a common finding, so include a step that deletes anything without a named owner. Set a rotation schedule that the team agrees on, based on how sensitive the content is and how hard the token is to replace in the consuming application. Rehearse each rotation in staging so the front end does not break during a live change. For administrators, confirm which accounts can still sign in with local passwords, whether the SSO local login lock-out is in use, and remove accounts for anyone who has left.
Monitoring should answer three questions: is someone guessing admin passwords, is the public API failing in ways that suggest a bug or abuse, and are rate limits holding. Watch failed admin login attempts, the share of 4xx and 5xx responses on public routes, and the number of requests that hit your rate limit settings. Set alert thresholds with the team, using a baseline from normal traffic. Strapi's audit logs are an Enterprise plan feature, so a self-hosted Community or Growth deployment may need a log pipeline outside Strapi. Confirm which events your Strapi version writes to application logs, then forward those logs and reverse proxy logs to a central store with the retention your policy requires. Test one alert end to end before relying on it.
Backups must cover the database and the media that Strapi serves. If uploads sit on the application server, back them up in the same recovery window as the database, or content will point to files that no longer exist. Restores are the test that matters, so schedule a restore into a separate environment and check that the admin panel, content and media all return. Keep a copy from before every upgrade, because Strapi's migration guidance says downgrading is not supported. For updates, agree a cadence for Strapi 5 minor releases, which have shipped roughly weekly, for example v5.57.0 on October 7, 2026 and v5.58.0 on October 14, 2026. Track Node.js LTS dates as well, since Strapi 5 runs only on Active or Maintenance LTS versions. Upgrade procedures are covered in the upgrades section of this page.
Dependency advisories need an owner too. Review security advisories for Strapi, its plugins and the Node.js packages in your lock file on a schedule, and decide in advance what triggers an out-of-cycle patch. Then write the configuration baseline: a single document, kept under version control, that records each role's permissions, each token's scope, the network rules that expose the admin panel and API, where secrets live, the CORS origins, the rate limit settings, and the Strapi and Node.js versions in production. Every change to these items should update the baseline in the same change. When an auditor or a new engineer asks what is exposed, the answer should be in one document that the team trusts.
Questions teams ask before hardening a Strapi project
How much does Strapi security hardening cost and what recurs?
Strapi security hardening is priced from the written scope, and DeployOpen does not publish a price list. The one-time portion covers the review of roles and public permissions, API token scope, admin panel exposure, secrets and environment configuration, CORS and rate limiting, and the first dependency patching pass. Recurring costs sit outside the engagement: Strapi plan fees if you buy Growth or Enterprise (Growth is listed at 45 US dollars per month including 3 users, per Strapi's self-hosted pricing page), Strapi Cloud subscriptions if you host there instead of self-hosting, database and storage, and an optional retainer for ongoing patching. Ask any quote to separate one-time work from recurring items and to name the environments it covers.
How long does Strapi security hardening take to complete?
The duration depends on how much of the project is exposed and how many environments must change. A project with a few public endpoints and one environment is usually shorter than one with several front ends, plugins and custom controllers that each need a permission review. Other drivers include whether the admin panel must sit behind a network boundary or an identity provider, how far behind the current Strapi and Node.js versions the project is, and how quickly your team can test changes in staging. Strapi ships minor releases often, so the starting version matters. Ask for the duration in writing with the scope, the environments covered and the testing time your team must provide.
Can an in-house team harden a Strapi project without outside help?
An experienced in-house team can do this, but the work spans Strapi, the database, Node.js, infrastructure and security testing. Someone needs to understand Strapi's roles and permissions model and the Users and Permissions plugin for end-user access. Someone needs to scope API tokens and check what each token can reach. A platform engineer needs to manage secrets, environment variables, TLS and network exposure for the admin panel. A developer should test CORS and rate limiting from the front end, and someone must own dependency scanning and patching on a schedule. Teams without these skills often spend longer learning which controls matter. Decide early who owns patching after launch, since it is the control most often neglected.
What does a Strapi hardening engagement need from our team?
The work needs access, an inventory and decisions from your team. Provide access to staging and production, or a clone of them, along with source code and configuration in version control. Share the database connection details so reviewers can check data exposure, and the admin panel URL and login method. Build a list of every API consumer, including front ends, mobile apps, scheduled jobs and third parties, with the token and role each one uses. If SSO is in scope, provide the identity provider details and the administrator group mapping, and confirm whether local login may be locked out. Name a technical owner who can approve changes and a test window. Access should be scoped and time-limited, and credentials should be rotated when the engagement ends.
Does hardening a Strapi project make it compliant with a standard?
No. Hardening reduces risk and produces evidence, but it does not make a Strapi project compliant with any framework. Independent auditors and certification bodies assess compliance and issue any attestation or certificate. DeployOpen prepares systems, configuration and evidence for compliance assessments, such as documented role matrices, token inventories, secret handling records and patch logs, but it does not issue audit reports or certifications. Ask your auditor which evidence they will accept, and map each control your framework requires to a specific hardening change. Also identify requirements that sit outside Strapi entirely, such as hosting location, backup retention and staff access procedures.
Do we need a Strapi Enterprise plan for security features?
Not for most hardening controls. Strapi's self-hosted pricing page lists audit logs and review workflows as Enterprise features, and SSO for the admin panel as an add-on on Growth or included in Enterprise. Most hardening work is configuration: tightening public role permissions, scoping API tokens, restricting the admin panel path, moving secrets into environment variables, setting CORS to known origins, configuring rate limiting at the server or proxy layer, and patching dependencies. These controls do not depend on a paid plan. Check the pricing page before you decide, since plan details change. If your policy requires audit logs or administrator SSO, the quote should show that plan cost separately from the hardening work.
How do we harden an existing Strapi project built with permissive defaults?
Start with an inventory and a permission review, then change the defaults in a staging copy before production. Export the current role and public permissions, list every endpoint reachable without authentication, and identify tokens with full access. Close public routes that front ends do not need, move each consumer to a narrowly scoped token, and verify every change with the same requests your front end makes. Next, move secrets out of committed files, restrict the admin panel and set CORS to known origins. Back up the database before each production change, schedule changes so you can roll back, and retest after each step. If the project runs Strapi v4, note that v4 reached end of life on April 30, 2026, so hardening and upgrade planning should be sequenced together.
How DeployOpen scopes, hardens and hands over Strapi security work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Strapi security hardening, we start from a written scope covering the public API, admin panel, tokens, secrets and dependencies, then build, test and document each change so your team can run it after handover.
How we scope
- Inventory every public REST and GraphQL endpoint and the roles that can reach it today.
- Agree in writing which Strapi environments, hosts and admin users fall inside the hardening scope.
- Confirm your self-hosting setup, Node.js version and database engine before any change is planned.
How we build
- Tighten public role permissions and API token scopes, then test each route with unauthenticated and authenticated requests.
- Move secrets and environment values out of code, and restrict admin panel exposure to approved networks or identity controls.
- Configure CORS origins and rate limiting, and patch dependencies with a tested update path for Strapi and its plugins.
How we hand over
- Provide a written record of permission matrices, token inventories, environment settings and the verification steps used.
- Walk your engineers through the changes and the rollback steps, so they can repeat checks without DeployOpen present.
- Deliver the work against the agreed scope, with open items and client decisions listed separately.
How we support
- Ongoing support for Strapi security is available as a retainer, covering dependency patching and periodic permission reviews.
- Retainer scope, response expectations and review cadence are set in writing before the retainer starts.
- Ask us to confirm which support items sit in the retainer and which need a separate, scoped change.
