Headless CMS

Definitions & benefits

Tools & Concepts

Open source

Features

Authentication

Custom plugins & Marketplace

Webhooks

Multilingual CMS

APIs

Dynamic Zones

User roles & permissions

Content Modeling

Security & Privacy

Use Cases

Ecommerce

Blog

Forum

About Strapi

Life at Strapi

Releases & Roadmap

Events

Community

News

The Tutorials section covers an introduction to Strapi, some advanced technical content, product updates and releases. From basic workaround to in-depth development guides. 

Tutorials

How tos

Get all the latest updates, news and events.

Subscribe to the newsletter 📣

In web security, authentication stands as a cornerstone for safeguarding sensitive data. Two prevalent methods, API tokens and JSON Web Tokens (JWTs), play pivotal roles in this landscape.

This guide provides the exploration of these mechanisms, offering insights into their generation, management, and implementation in Strapi CMS and in building fortified web applications.

## Prerequisites

The following are required to follow along with this tutorial:

- [NodeJs](https://nodejs.org/en/download/) installation on our local machine.
- [Postman](https://www.postman.com/downloads/) installation on our local machine.
- A Good understanding of Strapi - [get](https://strapi.io/documentation/developer-docs/latest/getting-started/introduction.html) [started](https://docs.strapi.io/dev-docs/quick-start) with this quick guide.
- Basic knowledge of authentication concepts.
## What is Authentication?

Authentication checks if an entity is who they say they are before letting them access resources.

### Authentication Types

There are several authentication methods. These include:

- **Username and password authentication:** This is the most common form, where users provide a username and password to access server resources.
- **Two-factor/Multi-factor authentication (2FA/MFA):** Users must provide more than one verification method before being granted access.
- **Biometric authentication:** This utilizes users' physical uniqueness, such as fingerprints, facial recognition, or voice recognition.
- **Single Sign-On (SSO):** Users authenticate once with a central service and access multiple applications without separate logins (e.g., Google authentication).
- **Token-based authentication:** This uses unique tokens (e.g., API keys, JWTs) for verification instead of usernames and passwords.
## What is a REST API?

A REST API is an application programming interface that conforms to the design principles of the *representational state transfer* (REST) architectural style.

REST APIs communicate through HTTP requests to perform standard database functions like creating, reading, updating and deleting records (also known as **CRUD**) within a resource.

## Authentication Strategies in Strapi

In this article, we will only explore the authentication strategies in Strapi or Strapi authentication methods. They are [**API Tokens**](https://docs.strapi.io/dev-docs/configurations/api-tokens) and [**JWT Tokens**](https://docs.strapi.io/dev-docs/plugins/users-permissions#jwt-configuration).

API tokens are built into Strapi CMS and found in the admin panel. Whereas the Users and Permission Plugin provides authentication using JWT tokens.

Without managing user accounts or making changes in the Users & Permissions plugin, users or applications can access resources using API tokens. With this, any unmanaged user or application can access resources if they make authenticated requests using an API token.

Unlike API tokens, the Users & Permissions plugin creates an access layer. With the access layer, users are matched and determine whether they can access a resource. This plugin uses JWT to authenticate users. 

There must be an `Authorization` header with the JWT token to make authenticated requests. It should be in the bearer-token scheme, `Bearer your-api-token`.

## Understanding API Tokens
### What are API tokens and their role in authenticating and authorizing API requests?

![001-api-token-cycle.png](https://api-prod.strapi.io/uploads/001_api_token_cycle_c15da0c9a5.png)


API tokens are unique identifiers or codes that grant users or applications access to an API. These tokens are uniquely created for each client and validated by the API before access to a resource gets granted.

They allow users or clients to make requests as authenticated users.

## The Basics of JSON Web Tokens (JWTs)
![002-jwt-token-cycle.png](https://api-prod.strapi.io/uploads/002_jwt_token_cycle_76ffbc03bd.png)


JWT or JSON Web Tokens is a standard for providing a secure and efficient way to transmit information representing claims between two parties.

They are used for authentication and authorization mechanisms and information exchange.

### Structure

The JWT comprises three structures: the **header**, **payload**, and **signature**.

- **Header**: This comprises of 2 parts. "Type", which is JWT and the "signature". The signature can be HS256, RSA, etc. The signature defines the signing or hashing algorithm used. See example below:
- 
```
{
  "alg": "HS384",
  "typ": "JWT"
}

```

- **Payload**: The payload contains the claims of the user. See example below:
```
{
  "id": "1",
  "name": "Strapi User",
  "admin": false
}

```

- Signature: By signing the encoded header, the encoded payload, a secret and the algorithm specified in the header, we get the signature. It ensures that the information sent remains unchanged along the way.
## Differences and Similarities
![003-difference-between-api-token-and-jwt-token.png](https://api-prod.strapi.io/uploads/003_difference_between_api_token_and_jwt_token_66017b0a90.png)

## Pros and Cons
- API tokens do not necessarily require authentication to generate one. There must be authentication to generate a JWT token,
- Unlike API tokens, JWT tokens are stateless and eliminate the need for server-side management.
- API tokens have a payload size smaller compared to JWT tokens. JWT tokens payload size can become bloated with excessive payload data.
- JWT tokens can be issued and validated by different parties. API tokens are dependent on the issuer’s availability and reliability.
- JWT tokens are flexible in adding additional user information to the payload. API tokens are limited in the authentication context.
## Create a Collection Type

To carry out the implementation of API tokens and JWT tokens, we need to create a collection type. 

Using the [Content-Type Builder](https://docs.strapi.io/user-docs/content-type-builder), create a collection type called `Product` and create a single field for it called `name`. The `name` field should be of type `text` (short text), required, and unique. 

![004-create-product-collection-type.png](https://api-prod.strapi.io/uploads/004_create_product_collection_type_4fa1d31e5d.png)


The collection type represents products that we can buy, and the `name` is the product name. 

Using the [Content Manager](https://docs-next.strapi.io/user-docs/content-manager), proceed to create entries in the collection type:


![005-field-types.png](https://api-prod.strapi.io/uploads/005_field_types_68249cd0e9.png)


Our collection type is ready to be accessed. Let us proceed to make some requests using Postman.

> NOTE: Remember to click **“publish”** when creating an entry in our collection.

## Implementing API tokens in Strapi CMS
### API Tokens in Strapi
In Strapi, API tokens can be managed in the admin panel. Administrators can manage API tokens from ***Settings*** *>* ***Global settings*** *>* ***API Tokens***.

![006-create-api-token-panel.png](https://api-prod.strapi.io/uploads/006_create_api_token_panel_73da797dc6.png)

### Creating an API Token
Creating an API token requires that we give it a name, as shown below. The description is optional. The token duration is required and set to 7 days, 30 days, 90 days or unlimited. The token type can be **full access**, **custom** or **read-only.**

![007-create-api-token.png](https://api-prod.strapi.io/uploads/007_create_api_token_53c943bbfd.png)

### API Token Types
**Full Access API Token**
With the full-access tokens, users get granted permission. They can make requests to any route of the Product collection. As can be seen, all actions on the product route are allowed by default and can’t be modified.

![008-full-access.png](https://api-prod.strapi.io/uploads/008_full_access_490f1328c7.png)

**Custom API Token**
By using custom API tokens, one can customize access to the product route and modify actions. As depicted in the image below, we can restrict access to the create action on the Product collection route.

![009-custom-access.png](https://api-prod.strapi.io/uploads/009_custom_access_89fe961403.png)

**Read-only API Token**
The read-only API token type only grants access to the read-only actions, the `find` and `findOne`. Requests to update, create or delete a resource in the Product collection will be forbidden. See the image below.

![010-read-only.png](https://api-prod.strapi.io/uploads/010_read_only_a7a9a7f803.png)

We will use the full access token type and set the token expiration to 7 days. See the image below.

![011-create-an-api-token.png](https://api-prod.strapi.io/uploads/011_create_an_api_token_67fd023e36.png)

> **NOTE**: Ensure to copy the token before leaving the page.

### Make Requests Using Postman
Products are available on our Strapi server. We need to be able to send HTTP requests that will allow clients or users to perform **CRUD** operations on these product resources. [Postman](https://www.postman.com/) will be our tool for making requests to the Strapi REST API.

### Fetch all Products (Unauthenticated Request)
We will start by fetching all the products in our Strapi backend. As shown in the image below, this route gets protected by default, and the request is forbidden. So, to fetch all products, we must make an authenticated request. 

![012-fetch-all-products.png](https://api-prod.strapi.io/uploads/012_fetch_all_products_ab1cacb955.png)

### Fetch all Products (Authenticated Request)
In the request header, using the bearer-token scheme, add the **“Authorization”** header with the generated API token.

![013-fetch-all-products-authenticated.png](https://api-prod.strapi.io/uploads/013_fetch_all_products_authenticated_6dfdb9d871.png)

Also, we can add the API token by clicking the Authorization tab in Postman. Select `Bearer Token` from the dropdown and enter the API token.

![014-add-authorization-header-2.png](https://api-prod.strapi.io/uploads/014_add_authorization_header_2_268265f7f4.png)


Now, when we make a request to get all products, it will be granted.

![015-successful-fetch-products.png](https://api-prod.strapi.io/uploads/015_successful_fetch_products_27b2e40fc9.png)

### Update a Product

With the API token, we can make an update to a product. Let us change the name of the first product item. 
Start by adding the token to the `Authorization` header, as shown in the image below:

![016-api-token-to-put-request.png](https://api-prod.strapi.io/uploads/016_api_token_to_put_request_d6d967da8c.png)

Proceed by adding the request body and making the request. As can be seen in the image below, the `PUT` request was successful.

```
{
  "data": {
    "name": "MacBook Pro 2024"
  }
}

```

![017-successful-api-token-with-put.png](https://api-prod.strapi.io/uploads/017_successful_api_token_with_put_d5c3473d55.png)


Continue by making `CREATE` and `DELETE` requests.

## **Sending JWTs with Postman**
### JWT Tokens in Strapi

In Strapi, the Users and Permissions Plugin provides us with authentication through JSON Web tokens. 

When we click the **Settings** link, under the **USERS & PERMISSIONS PLUGIN** section, we will find sections for managing **Roles**, **Providers**, **Email Templates**, and **Advanced Settings**.

The **Role** permissions come in 2 kinds: **Authenticated** and **Public****:**

- Authenticated is for permissions given to authenticated users.
- Public is for permissions granted to unauthenticated users.

**Set Public Endpoints**
Now, click the **Public >** **Product**, and select only `find` and `findOne` endpoints. Users will access these endpoints without authentication or authorization. With this in place, unauthenticated users can see all products and any product by their ID.

![018-set-public-endpoints.png](https://api-prod.strapi.io/uploads/018_set_public_endpoints_25d96a89d8.png)

**Set Authenticated Endpoints**
Click on **Authenticated** > **Product**, and click on `Select All`.
With this in place, authenticated users can access all endpoints related to the `Product` collection.

![019-set-authenticated-endpoints.png](https://api-prod.strapi.io/uploads/019_set_authenticated_endpoints_2843b0d9bd.png)

### Generating JWT Tokens

To generate a JWT token, a user must first make an authentication request. An authentication request body must include the `password` and `identifier` of the user. The `identifier` could be their username or email.

There are 2 ways to create a user. We can create the user in the admin panel or make a POST request to the `/api/auth/local/register` endpoint. Let us do the latter:

![020-post-request-create-user.png](https://api-prod.strapi.io/uploads/020_post_request_create_user_1bec3479e7.png)

In the image above, the request body includes the `username`, `email` and `password` of the new user. Upon successful request, the JWT token, along with other data, gets returned as shown below:

![021-successful-create-user-with-jwt.png](https://api-prod.strapi.io/uploads/021_successful_create_user_with_jwt_a29619486a.png)


From the image above, the JWT in the response body represents the JWT token the new user can use to make authenticated requests.

Once the JWT token expires, we can make a `**POST**` request to the `/api/auth/local` endpoint to get a new one. In the body request, we will only supply the user’s username or email as an `identifier` and their `password`.
```
{
  "identifier": "user@strapi.io",
  "password": "strapiPassword"
}

```

![022-login-request.png](https://api-prod.strapi.io/uploads/022_login_request_c76451e49d.png)


Upon success, the following gets returned.

![023-create-jwt-through-login.png](https://api-prod.strapi.io/uploads/023_create_jwt_through_login_d5c14a93cb.png)

### Create a Product

With the JWT token, we can perform all the actions related to the `Product` collection endpoint. For this reason, let us create a product. Using the bearer-token schema, add the JWT token to the `Authorization` header.

![024-add-jwt-to-authorization-header.png](https://api-prod.strapi.io/uploads/024_add_jwt_to_authorization_header_195219d09e.png)


Add the following as the request body in Postman.
```
{
  "data": {
    "name": "PlayStation 5 (PS5)"
  }
}

```

![025-post-request-to-create-product.png](https://api-prod.strapi.io/uploads/025_post_request_to_create_product_c095677249.png)

Upon successful request, the following gets returned.

![026-successful-create-product.png](https://api-prod.strapi.io/uploads/026_successful_create_product_dc30d3f690.png)

### Delete a Product

Next, let us delete a product. To delete a product, we will make a `DELETE` request to the `/api/products/[id]` endpoint. The `[id]` here represents the ID of the product we want to delete.

Start by adding the JWT token to the `Authorization` header. 

![027-delete-request-with-jwt.png](https://api-prod.strapi.io/uploads/027_delete_request_with_jwt_7457232c81.png)

In the image above, we want to delete the product with an `id` of `1`. When we make the request, we get the following:

![028-successful-delete-request.png](https://api-prod.strapi.io/uploads/028_successful_delete_request_2fc7bae0a4.png)

## **Best Practices for API Token and JWT Management**

Because API tokens and JWT tokens are required to make authenticated requests, they should be managed and prevented from unwanted and malicious use.

- Ensure that HTTPS and SSL are used for all API communications to protect API tokens and JWT tokens.
- Ensure that there is secure Storage to store API tokens and JWT both on the client and server side.
- Implement Rate Limiting on endpoints to prevent brute-force attacks and limit the number of requests per unit of time.
- Monitor and audit API usage.
- Stay up to date with best security practices.
- Implement token expiry to reduce the risks of unauthorized access.
## **Conclusion**

In this article, we looked into the application of authentication and the REST API. We have discovered that in Strapi, there are two strategies for making authenticated requests: API token, JWT, and others.

When choosing an authentication strategy or any Strapi authentication method, we have to think in such a way that it will be efficient, applicable and not just problematic after. Such as, in comparison to the API tokens, JWT tokens are stateless, and they eliminate the need for server-side management, like storing tokens in the database. Also, in terms of their payload size, API tokens are more compact than JWT tokens, which are prone to get bloated due to more payload information.

It is important to apply security practices such as HTTPS and SSL, secure storage of the tokens, rate limiting, API monitoring, etc. so that authentification requests do not come from malicious access.

## **Additional Resources**
- ⁠https://docs.strapi.io/dev-docs/configurations/api-tokens
- ⁠⁠[https://docs.strapi.io/user-docs/settings/API-tokens](https://docs.strapi.io/user-docs/settings/API-tokens)
- [⁠⁠https://docs.strapi.io/dev-docs/backend-customization/examples/authentication](⁠⁠https://docs.strapi.io/dev-docs/backend-customization/examples/authentication)
- [⁠⁠https://strapi.io/blog/how-to-create-a-refresh-token-feature-in-your-strapi-application](⁠⁠https://strapi.io/blog/how-to-create-a-refresh-token-feature-in-your-strapi-application)
- [https://strapi.io/blog/a-beginners-guide-to-authentication-and-authorization-in-strapi](⁠⁠https://strapi.io/blog/how-to-create-a-refresh-token-feature-in-your-strapi-application)
- https://www.ibm.com/topics/rest-apis
- https://jwt.io/introduction



In web security, authentication stands as a cornerstone for safeguarding sensitive data. Two prevalent methods, API tokens and JSON Web Tokens (JWTs), play pivotal roles in this landscape.

large_Guide on authenticating requests with the REST API.jpg

medium_Guide on authenticating requests with the REST API.jpg

small_Guide on authenticating requests with the REST API.jpg

thumbnail_Guide on authenticating requests with the REST API.jpg

Guide on authenticating requests with the REST API.jpg

Guide on authenticating requests with the REST API

I am Theodore. A full-stack software developer and Technical Writer. I love building solutions, writing technical articles and sharing my expertise.

Writer

large_Custom Soft Delete with Strapi and NextJs 14_ Building a Recycle Bin.jpg

medium_Custom Soft Delete with Strapi and NextJs 14_ Building a Recycle Bin.jpg

small_Custom Soft Delete with Strapi and NextJs 14_ Building a Recycle Bin.jpg

thumbnail_Custom Soft Delete with Strapi and NextJs 14_ Building a Recycle Bin.jpg

Custom Soft Delete with Strapi and NextJs 14_ Building a Recycle Bin.jpg

Custom Soft Delete with Strapi and NextJs 14: Building a Recycle Bin

# Outline

- Introduction
- Overview of Policies
- Scenario
- Implementing Consent Policy
- Implementing Policy for Rate Limiting
- Implementing Policy for IP Addresses
- Implementing Input Validation Policy
- Account Lockout Policy
- Implementing Authorization and Authentication Policy
- Github Code
- Conclusion
- Resources

# Introduction

In this article, we will explore how to build a secure web application using the power of Strapi policies. With Strapi you can build and secure your web application using customizable policies including caching, rate limiting, data validation, authentication and authorization, ip whitelisting and much more. By the end of the article, you will have a solid understanding of how to build a secure web application with Strapi policies.

The primary focus of this article is the API security of a web application.

# Overview of Policies

Policies are sets of rules, guidelines, or predefined actions that govern various aspects of behavior, access, and decision-making within a system, organization, or application.

> Policies are functions that execute specific logic on each request before it reaches the [controller](https://docs.strapi.io/dev-docs/backend-customization/controllers). They are mostly used for securing business logic.

They are mostly for read-only operations. They are used to perform checks to ensure that the rules or specified guidelines are met.

When creating a [Strapi Policy](https://docs.strapi.io/dev-docs/backend-customization/policies) , a `true` or `false` is returned. The latter is for when the policy is met and the former is when the policy is not met. We could also throw a policy error in place of the `false` .

Let us head on to create some policies that will help secure an API.

# Scenario

The project of this article is a location based application. A user can create locations that are interesting and fun to visit so others can see it.

Using this idea, let us implement some policies.

# Implementing Consent Policy

A consent policy helps ensure that individuals have given informed and explicit consent before their data is collected, processed, or used in any way.

In a case where the user hasn’t consented, as shown below, they won’t be able to make requests to the `locations` route.

![001-policies-nextjs.png](https://api-prod.strapi.io/uploads/001_policies_nextjs_db20ccf825.png)

Head over to the `policies` folder inside the `src` folder and create a file called `consent.js` . Add the following code:

```javascript
// ./src/policies/consent.js
const { errors } = require("@strapi/utils");
const { PolicyError } = errors;

module.exports = async (policyContext, config, { strapi }) => {
  if (policyContext.state.user.agreeToPolicy) {
    return true;
  } else {
    const user = policyContext.state.user.username;
    throw new PolicyError(
      `Hi ${user}, Please agree to terms and conditions to continue.`,
      {
        policy: "consent-policy",
      }
    );
  }
};
```

In the policy file above, we checked if the user `jane_doe` has agreed to the terms and conditions of our application using the property `agreeToPolicy`. If true, they are allowed to access a particular route; otherwise, a content policy error is thrown.

Now add this as a global policy to the `location` route.

```javascript

// ./src/api/location/routes/location.js
module.exports = createCoreRouter("api::location.location", {
  config: {
    find: {
      middlewares: [
        ...
      ],
      policies: [
        "global::consent",
        "global::account-locked",
        "ip",
        "rate-limit",
      ],
    },
    create: {
      policies: ["location-input"],
    },
  },
});

```

Now, when `jane_doe` makes a request to the `location` route, she gets this response:

![002-policies-nextjs.png](https://api-prod.strapi.io/uploads/002_policies_nextjs_e9816a29dc.png)

# Implementing Policy For Rate Limiting

Here, we will implement a policy to check if a user has subscribed to a plan. With this policy we will add a middleware that will handle the number of requests a user can make in a day.

> "If you provide an API client that doesn't include rate limiting, you don't really have an API client. You've got an exception generator with a remote timer." – Richard Schneeman

Locate the `location` folder in the `./src/api/` folder and create a folder named `policies`. Inside this new folder, create a file named `rate-limit.js` and add the following code:

```javascript
// ./src/api/location/policies/rate-limit.js
const { errors } = require("@strapi/utils");
const { PolicyError } = errors;

module.exports = async (policyContext, config, { strapi }) => {
  if (policyContext.state.user.isSubscribed) {
    return true;
  } else {
    const user = policyContext.state.user.username;
    throw new PolicyError(`Hi ${user} Please subscribe to view locations`, {
      policy: "rate-limit",
    });
  }
};
```

In order for the policy to work, we need to add it to the `locations` route middleware that handles the request to get locations. Inside the `location` folder, locate the `location.js` file inside the `routes` folder and add the following code:

```javascript
// ./src/api/location/routes/location.js
"use strict";

/**
 * location router
 */
const { createCoreRouter } = require("@strapi/strapi").factories;
const { rateLimit } = require("express-rate-limit");

// rate limiting
const fiveReqLimits = rateLimit({
  windowMs: 24 * 60 * 60 * 1000, // 1 day,
  max: 5, // 5 requests,
  // get ip address of user since it is required
  keyGenerator: (request, response) => {
    let ip = strapi.requestContext.get().request.ip;
    return ip;
  },
  handler: async (request, response, next) => {
    const ctx = strapi.requestContext.get();
    ctx.status = 403;
    ctx.body = {
      message:
        "You have exhausted your 5 requests for the day. Please check back tomorrow.",
      policy: "rate-limit",
    };
  },
});

const tenReqLimits = rateLimit({
  windowMs: 24 * 60 * 60 * 1000, // 1 day,
  max: 10, // 10 requests,
  handler: async (request, response, next) => {
    const ctx = strapi.requestContext.get();
    ctx.status = 403;
    ctx.body = {
      message:
        "You have exhausted your 10 requests for the day. Please check back tomorrow.",
      policy: "rate-limit",
    };
  },
});

module.exports = createCoreRouter("api::location.location", {
  config: {
    find: {
      middlewares: [
        async (ctx, next) => {
          const ip = ctx.request.ip;
          if (ctx.state.user.plan === "basic") {
            fiveReqLimits(ctx.req, ctx.res, (error) => {
              if (error) {
                ctx.status = 500;
                ctx.body = { error: error.message };
              }
            });
          } else {
            tenReqLimits(ctx.req, ctx.res, (error) => {
              if (error) {
                ctx.status = 500;
                ctx.body = { error: error.message };
              }
            });
          }
          await next();
        },
      ],
      policies: ["rate-limit"],
    },
  },
});
```

In the code above, we added a middleware that will handle the `find` method of the `/locations` route. This means that this middleware handles the `GET` HTTP request to the `/locations` route. If the user is on the `basic` plan, we invoke the rate limit for five requests a day. Else, we invoke the rate limit of ten request per day. And we included the `rate-limit` policy in `line 68`.

> NOTE: The name of our policy file `rate-limit.js` should be the same as the name of our policy `rate-limit` that we added.

Using the following data:

![003-policies-nextjs.png](https://api-prod.strapi.io/uploads/003_policies_nextjs_b3dba1c777.png)

As we can see, `user1` is on the free plan with the `unSubscribed` field as `false`. `user2` and `user3` are both subscribed and on the `basic` and `standard` plans.

For the `basic` plan, a user can only make requests 5 times a day. Unlike the standard plan which is 10 times a day.

When `user1` makes request to get random locations, they get a policy error that they need to subscribe.

![003-5-policies-nextjs.png](https://api-prod.strapi.io/uploads/003_5_policies_nextjs_209ea9c981.png)

When `user2` makes a request to get random locations, their rate limit decreases by 1.

![004-policies-nextjs.png](https://api-prod.strapi.io/uploads/004_policies_nextjs_f4b75f2a7c.png)

As we can see, on the first request, their number of requests, `X-RateLimit-Limit`, is reduced to `4`, which is the `X-RateLimit-Remaining`.

When `user3` makes a request to get random locations:

![005-policies-nextjs.png](https://api-prod.strapi.io/uploads/005_policies_nextjs_a79eec1aea.png)

Similar to `user2`, `user3` will only have 9 requests remaining.

When the maximum request limit has been reached, a policy error is thrown, as shown below:

![006-policies-nextjs.png](https://api-prod.strapi.io/uploads/006_policies_nextjs_95bf6e8248.png)

# Implementing Policy for IP Addresses

With a Strapi Policy, we can whitelist or backlist one or more IP addresses. This is to protect and filter out illegitimate or malicious IP addresses from your website. **filter out illegitimate or malicious IP addresses.**

Locate the `policies` folder and create a new policy file called `ip.js`. Inside this file, add the code below:

```javascript
// ./src/api/location/policies/rate-limit.js
const { errors } = require("@strapi/utils");
const { PolicyError } = errors;
const ip = require("koa-ip");

// ip addresses to blacklist
const blackList = ["77.88.99.1", "88.77.99.1", "127.0.0.1"];

module.exports = async (policyContext, config, { strapi }) => {
  const ip = policyContext.request.ip;
  if (blackList.indexOf(ip) > -1) {
    const user = policyContext.state.user.username;
    throw new PolicyError(
      `Hi ${user} Please this resource is not available to you`,
      {
        policy: "ip-blacklist",
      },
    );
  } else {
    return true;

};
```

In the code above, we created an array `blacklist` that will hold the IP addresses we want to block. Then we checked if the IP of the user, using `policyContext.request.ip` , making the request is any of the IPs. If it is in the blacklist, we throw a policy error, else the request will go through.

Now locate inside the `location.js` file inside the `./src/api/location/routes/` folder and add the `ip` policy to it. Ensure that it is before the `rate-limit` policy. This is so that it is first checked before the `rate-limit` policy is called.

    policies: ["ip", "rate-limit"]

When a user with any of the blacklisted IPs make a request, they get the following:

![007-policies-nextjs.png](https://api-prod.strapi.io/uploads/007_policies_nextjs_27150ec46e.png)

# Implementing Input Validation Policy

Though we could use the `beforeCreate` / `beforeUpdate` methods we could also set up policy for input validation.

We will implement a policy that validates inputs from the request body are valid before reaching our controller using [joi](https://www.npmjs.com/package/joi) validation package.

> **NOTE**: Strapi can handle this validations on its own. Yet a policy can be added before Strapi validates the inputs.

Create another policy called `location-input.js` inside the `policies` folder in the path `./src/api/location/` . Add the following code:

```javascript
// ./src/api/location/policies/location-input.js
const { errors } = require("@strapi/utils");
const { PolicyError } = errors;
const Joi = require("joi");

const schema = Joi.object({
  name: Joi.string().min(3).max(30).required(),

  address: Joi.string().min(5).max(100).required(),
});

module.exports = async (policyContext, config, { strapi }) => {
  const { data } = policyContext.request.body;
  const validationError = schema.validate(data)?.error?.details[0]?.message;
  if (validationError) {
    throw new PolicyError(validationError, {
      policy: "location-creation",
    });
  }
  return true;
};
```

In the code above, we created a schema that specifies the validations for the `name` and `address` fields. These fields are needed to create a new location in our `location` model. We validated the body of the request using this schema. If there is a validation error, we throw a policy error with the validation error message.

Next, we add this policy to the `create` function of the `location` route configuration.

```javascript
// ./src/api/location/routes/location.js
  ...
  module.exports = createCoreRouter("api::location.location", {
    config: {
      find: {
        ...
        // policies
        policies: [],
      },
      create: {
        policies: ["location-input"],
      },
    },
  });
```

Sending the `name` field as a number instead of a string.

![008-policies-nextjs.png](https://api-prod.strapi.io/uploads/008_policies_nextjs_896bbc9794.png)

![009-policies-nextjs.png](https://api-prod.strapi.io/uploads/009_policies_nextjs_90db6da46d.png)

This will throw the policy error:
When the input is correct and because we set the `name` field to be `unique` in Strapi, it will throw an error because we tried to create a new location with a name that already exists.

![010-policies-nextjs.png](https://api-prod.strapi.io/uploads/010_policies_nextjs_dedb43460c.png)

# Account Lockout Policy

Here, we will implement the policy to check if a user’s account is blocked until after some time. We will be using a 7 day period of lockout. If a user violates the terms and conditions of the application, their access to resources will be revoked for 7 days.

This policy will be a global policy. For this reason, inside the `src` folder, create a new folder `policies` . Inside this new folder, create a file called `account-locked.js` and add the following code:

```javascript
// ./src/policies/account-locked.js
const { errors } = require("@strapi/utils");
const { PolicyError } = errors;
const { DateTime } = require("luxon");

module.exports = async (policyContext, config, { strapi }) => {
  const dateOfLockout = DateTime.fromISO(
    policyContext.state.user?.dateOfLockout
  );
  const luxonDateTime = DateTime.now();

  const daysDifference = luxonDateTime
    .diff(dateOfLockout, ["days"])
    .toObject()?.days;

  // if lockout period has been exceeded
  if (daysDifference > 7) {
    return true;
  } else {
    let daysRemaining = dateOfLockout.day + 7 - luxonDateTime.day;
    const user = policyContext.state.user.username;

    throw new PolicyError(
      `Hi ${user}. Your account has been blocked. Check back in ${daysRemaining.toFixed()} days time`,
      {
        policy: "account-locked",
      }
    );
  }
};
```

In the code above, we made use of the `luxon` NPM package for our date formatter. We got the date when the user was locked out and the current date and time. We checked if the expiration period has elapsed. And made sure that they can now make requests, otherwise we throw the user a Policy error by adding the number of days remaining for the user’s account to be unlocked.

Next, we add this policy to the `location` route as a global policy.

```javascript
// ./src/api/location/routes/location.js
...
module.exports = createCoreRouter("api::location.location", {
  config: {
    find: {
      middlewares: [
        ...
      ],
      policies: ["global::account-locked", "ip", "rate-limit"],
    },
    create: {
      policies: ["location-input"],
    },
  },
});
```

When we a user’s account is blocked they get the following response as shown below:

![011-policies-nextjs.png](https://api-prod.strapi.io/uploads/011_policies_nextjs_5ebf4ee82a.png)

# Implementing Authorization and Authentication Policy

In this scenario, we have to create a policy that allows only a user with the field `isAdmin` to modify the `location` route.

Take a look at the user `ted` below whose `isAdmin` field is set to false. This means he is not an admin.

![012-policies-nextjs.png](https://api-prod.strapi.io/uploads/012_policies_nextjs_664a797bfd.png)

Now, locate the `policies` folder in the path `./src/api/location` and create a file called `is-admin` . Inside this new file, add the code below:

```javascript
// path: ./src/api/location/policies/is-admin.js
const { errors } = require("@strapi/utils");
const { PolicyError } = errors;

module.exports = async (policyContext, config, { strapi }) => {
  // check if user is admin
  if (policyContext.state.user.isAdmin) {
    // Go to controller's action.
    return true;
  }
  // if not admin block request
  const user = policyContext.state.user.username;
  throw new PolicyError(`Hi ${user}, you are not allowed to update this data`, {
    policy: "admin-policy",
  });
};
```

Locate the location route file and add this policy to the update function controller.

```javascript
// ./src/api/location/routes/location.js
module.exports = createCoreRouter("api::location.location", {
  config: {
    find: {
      middlewares: [
        ...
      ],
      policies: [
        "global::consent",
        "global::account-locked",
        "ip",
        "rate-limit",
      ],
    },
    create: {
      policies: ["location-input"],
    },
    update: {
      policies: ["is-admin"],
    },
  },
});

```

Next, the user `ted` , who is not an admin, wants to update the address of the location with `id` as 1 below:

![013-policies-nextjs.png](https://api-prod.strapi.io/uploads/013_policies_nextjs_0e0bbec96a.png)

![014-policies-nextjs.png](https://api-prod.strapi.io/uploads/014_policies_nextjs_676196bc00.png)

Now when `ted` makes a request, they get the following:
As we can see above, they are forbidden to make this request. When the user is an admin the request can successfully be executed as shown below:

![015-policies-nextjs.png](https://api-prod.strapi.io/uploads/015_policies_nextjs_e49c6c5f9c.png)

![016-policies-nextjs.png](https://api-prod.strapi.io/uploads/016_policies_nextjs_8c741315b1.png)
# Github Code

The complete code for this article can be found here: https://github.com/Theodore-Kelechukwu-Onyejiaku/strapi-policy-usecases

# Conclusion

There are lots of ways to ensure API and web security and Strapi Policies help in achieving this. With Strapi Policies, we have been able to demonstrate the use of policy for authorization, rate limiting, IP filtering, input validation, account lockout, and so on to ensure web security of our applications. Join the Strapi [Discord community](http://discord.com/invite/strapi) for more.

# Resources

- Strapi Policies : https://docs.strapi.io/dev-docs/backend-customization/policies