> Portal Navigation:
> 
> - Append `.md` to any URL under `https://dev.wix.com/docs/` to get its markdown version.
> - Pages are either content pages (article or reference text) or menu pages (a list of links to child pages).
> - To get a menu page, truncate any URL to a parent path and append `.md` (e.g. `https://dev.wix.com/docs/sdk.md`, `https://dev.wix.com/docs/sdk/core-modules.md`).
> - Top-level index of all portals: https://dev.wix.com/docs/llms.txt
> - Full concatenated docs: https://dev.wix.com/docs/llms-full.txt

## Resource: Elevate API Call Permissions

## Article: Elevation

## Article Link: https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/authorization/elevate-api-call-permissions.md

## Article Content:

# Elevate API Call Permissions

> **Note:** This article discusses elevation when extending websites, but the concepts and implementation are the same when [coding in Blocks](https://dev.wix.com/docs/build-apps/develop-your-app/develop-an-app-with-blocks/code-in-blocks/about-coding-in-blocks.md).

[Elevation](https://dev.wix.com/docs/overview/auth-permissions/elevation.md) lets you call restricted Wix API methods even when the current identity lacks the necessary permissions.

> **Note:** Due to potential security risks, you can only elevate methods in backend code.

## Elevate a method

Use the `elevate()` function from `wix-auth`:

```javascript
import { elevate } from "wix-auth";
import { someModule } from "wix-some-module";

//...

const elevatedMethod = elevate(someModule.methodName);
elevatedMethod(param1, param2);
```

## When elevation is needed

Methods can be restricted based on user [identity](https://dev.wix.com/docs/overview/auth-permissions/identities.md) or [roles and permissions](https://dev.wix.com/docs/overview/auth-permissions/permissions.md):

- **Identity-restricted methods** can only be called by [Wix users](https://dev.wix.com/docs/overview/auth-permissions/identities.md#wix-user). For example, [`assignBadge()`](https://dev.wix.com/docs/velo/apis/wix-members-v2/badges/assign-badge.md) requires elevation when called outside a dashboard page, since site members can't assign badges to themselves.
- **Role-restricted methods** require specific roles. For example, [`confirmBooking()`](https://dev.wix.com/docs/velo/apis/wix-bookings-v2/bookings/confirm-booking.md) requires elevation when called on behalf of a user without an administrative Bookings role.

## Security considerations

While elevation offers flexibility, it's crucial to consider how and when elevation is triggered. [Web methods](https://dev.wix.com/docs/velo/apis/wix-web-module/web-method.md) and [HTTP functions](https://dev.wix.com/docs/velo/velo-only-apis/wix-http-functions/introduction.md) are particularly vulnerable if not properly managed due to their open nature. Elevation in [backend events](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/backend-code/events/about-backend-events.md) or code only triggered from [scheduled jobs](https://dev.wix.com/docs/develop-websites/articles/workspace-tools/developer-tools/recurring-jobs/about-scheduling-recurring-jobs.md) presents less risk but should still be handled cautiously.

### Example

To demonstrate how to properly handle elevation, consider a site that rewards frequent visitors with a special badge. To do so, the code needs to track recent member visits and call `assignBadge()` using elevation when a member has visited frequently enough. (Note that the code samples below have been simplified, removing error handling and other non-essential code.)

Here is an example of an insecure approach to writing this code:

```javascript
// Backend code in badges.web.js
import { elevate } from "wix-auth";
import { Permissions, webMethod } from "wix-web-module";
import { badges } from "wix-members.v2";

export const assignBadge = webMethod(
  Permissions.Anyone,
  (badgeId, memberId) => {
    const elevatedAssignBadge = elevate(badges.assignBadge);
    return elevatedAssignBadge(badgeId, [memberId]);
  }
);

export const isFrequentVisitor = webMethod(Permissions.Anyone, (memberId) => {
  // Query collection that tracks member visits,
  // determine if the specified member is a frequent visitor,
  // and return the result
});

// Frontend code in masterPage.js
import { assignBadge, isFrequentVisitor } from "backend/badges.web";
import { members } from "wix-members.v2";

const frequentVisitorBadgeId = "c705b8dd-aae2-4eea-a4d1-16f52421ec0a";

//...

const currentMember = await members.getCurrentMember();

if (isFrequentVisitor(currentMember._id)) {
  assignBadge(frequentVisitorBadgeId, currentMember._id);
}
```

There are several problems with the `assignBadge()` web method used in this approach:

- It is open for anyone to call, even though only members can receive badges.
- It doesn't ensure that it will only assign the intended badge.
- It doesn't ensure that it will assign a badge to the currently logged in member.

Because of these issues, this method can be called by a malicious user to assign any badge to any member.

You can easily remedy these issues by being more careful about where you use elevation and how you expose it to be called.

For example:

```javascript
// In badges.web.js
import { elevate } from 'wix-auth';
import { Permissions, webMethod } from "wix-web-module";
import { badges } from "wix-members.v2";
import { members } from 'wix-members.v2';

const assignFrequentVisitorBadge = webMethod(
  Permissions.Member,
  () => {
    const currentMember = await members.getCurrentMember();
    if (isFrequentVisitor(currentMember.\_id)) {
    const frequentVisitorBadgeId = 'c705b8dd-aae2-4eea-a4d1-16f52421ec0a';
      const elevatedAssignBadge = elevate(badges.assignBadge);
      return elevatedAssignBadge(frequentVisitorBadgeId, [memberId]);
    }
  }
)

const isFrequentVisitor = (memberId) => {
  // Query collection that tracks member visits,
  // determine if the specified member is a frequent visitor,
  // and return the result
}

// masterPage.js
import { assignFrequentVisitorBadge } from 'backend/badges.web';

//...

assignFrequentVisitorBadge();
```

In this approach, the following makes sure the elevation is not exploited by malicious users:

- The ID of the badge to assign is specified in backend code.
- The current user ID is retrieved in backend code.
- The web method used to trigger the badge assignment has permissions set so it can only be called by site members.

## See also

- [About Identities](https://dev.wix.com/docs/overview/auth-permissions/identities.md)
- [Roles & Permissions](https://support.wix.com/en/article/roles-permissions-overview)
- [elevate()](https://dev.wix.com/docs/velo/apis/wix-auth/elevate.md)