API Security

  1. Input validation
  2. Using Secure Sockets Layer (SSL) protocol
  3. Validating content types
  4. Maintaining audit logs
  5. Protecting against cross-site request forgery (CSRF)
  6. Protecting against cross-site scripting (XSS)

Authentication and Authorization

The process of verifying who you are is Authentication. Web applications usually accomplish this by asking you to log in with a username and password. This combination is checked against an existing username/password record to ensure the request is authentic.

Basic Authentication

I’s the simplest technique used to enforce access control on the web. The clients send HTTP requests with an Authorization header which consists of the work “Basic” followed by a space and a string generated by combining username and password with colon (username:password) and encoding it with base64.

Authorization: Basic dXNlcjpwYXNzd2yZA==
  1. The password is sent over the wire in base64 encoding which can be easily converted into plaintext
  2. SSL can solve #1 but once on the server side, the password may be routed in plaintext after SSL termination
  3. Applications are required to store these credentials in plaintext or in a way that they can decrypt them
  4. #3 can be solved using SALT and one-way hash techniques but is a security overhead
  5. The password may be cached on the browser, if user permits. This can be stolen by the any user on the shared machine


It is an open standard that allows users to grant access to applications without sharing passwords with them.

  1. The biggest benefit of OAuth is that users do not need to share passwords with the applications. For example, TripAdvisor wants to build an application that will use a user’s Facebook identity, profile, contact list and other FB data. With OAuth, tripAdvisor can redirect the user to Facebook, where they can authorize TripAdvisor to access their information. After the user authorizes the sharing of data, tripAdvisor can then call the Facebook API to fetch this information.
  2. Second benefit is thet API providers’ users can grant selective permissions. Each application has different requirements of what data it needs from an API provider. For example, TripAdvisor would receive permission to read a user’s profile, contacts and more but it cannot post on Facebook on user’s behalf.
  3. If at any point a user would like to revoke TripAdvisor’s access to their Facebook data, they can simply go to their Facebook settings and revoke it without changing their password.
  1. Applications typically show users a button labeled “Continue with Facebook” or “Continue with Google”. When users click the button, they are redirected to the API provider’s authorization URL. While redirecting, the application sends client ID, the permissions requested in a parameter called scope, an optional unique state parameter and (optionally) a redirect URL.
  2. The API provider should clearly indicate what permissions the application is requesting. If the user denies the authorization, they are redirected back to the application’s redirect URL with an access_denied error. If the user approves the request, they are redirected back to the application with an authorization code.
  3. Upon successful authorization, the application sends the client ID, client secret, authorization code and redirect URL to the API provider to receive an access token. The authorization code provided can only be used once; this helps in preventing replay attacks. Applications can then use this access token to access resources on user’s behalf.
POST /api/chat.postMessage
HOST slack.com
Content-Type: application/json
Authorization: Bearer xoxp-1504398475-a24afg879
"text":"This is the message text",
"attachments":[{"text":"attachment text"}]
  1. Access token is valid by matching the given access token with the granted access token in your database
  2. The access token has the required scope for the action that the request is supposed to perform
"ok": false,
"error": "missing_scope",
"needed": "chat:write:user",
"provided": "identify,bot,users:read"
  1. If an access token is compromised, it will work only until it expires.
  2. If a refresh token is compromised, it will be useless without the client secret, which is typically not stored with access tokens or refresh tokens.
  3. If both the refresh token and the client secret are compromised and the attacker generates a new access token, the compromise can potentially be detected because typically refresh tokens are one-time use only.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Priyanka Masne

Priyanka Masne

Software Developer by day, Equity Investor by night