Skip to main content

API scanning authentication methods

This section explains the following authentication methods you can use when you configure API Scanning.

Client certificate

Use for authenticating with servers configured with TLS authentication. API Scanning responds to any client certificate requests for certificates from a matching issuer with the configured certificate. Ensure the file format of the certificate is PKCS#12, which usually has a .pfx or .p12 extension. Also, you must specify a passphrase that decrypts the private key in the .p12 file.

Basic authentication

Use basic and NTLMv2 authentication for authenticating with internal servers. API specifications that use basic authentication typically have scheme: basic defined in their OpenAPI definitions. For example, in OpenAPI 3.0:

type: http
scheme: basic # specifies to use basic authentication.

Custom headers

Common type of authentication for use with Veracode API Scanning. You can define one or more name/value pairs. When defining the name, do not add any trailing colons. Values typically do not include a colon, but this is legal according to the RFC. You cannot use these reserved header names:

  • Accept-Charset
  • Accept-Encoding
  • Access-Control-Request-Headers
  • Access-Control-Request-Method
  • Connection
  • Content-Length
  • Cookie
  • Cookie2
  • Date
  • DNT
  • Expect
  • Host
  • Keep-Alive
  • Origin
  • Referer
  • TE
  • Trailer
  • Transfer-Encoding
  • Upgrading
  • Via

Custom headers in OpenAPI specifications use apiKey or bearerAuth security scheme types. Because authentication might occur at a different layer of the solution, such as through an API gateway, you might not need to add it to the API specification. Ensure you check with the development team that created the specification to confirm the authentication solution.

This example shows a custom header with the name X-API-KEY:

openapi: 3.0.0
ApiKeyAuth: # arbitrary name for the security scheme
type: apiKey
in: header # can be "header" or "cookie"
name: X-API-KEY # name of the header, query parameter, or cookie

This example shows a JWT bearer token:

openapi: 3.0.0
bearerAuth: # arbitrary name for the security scheme
type: http
scheme: bearer
bearerFormat: JWT

You can configure this token as a custom header with name Authorization and value Bearer $JWT_CONTENT, where $JWT_CONTENT is a series of period-delimited, base64-encoded JSON fragments.

OAuth 2.0

Authenticate with servers that require the OAuth 2.0 protocol. API Scanning supports both the Client Credentials and Password Credentials grant types, which you can select from the Grant Types dropdown menu. For both grant types, a scope is optional. If you need to enter multiple scope values, separate each value with a space. Veracode sends all authorization data as an HTTP Authorization Header.

If you select the Client Credentials grant type, you can select the Use OpenID Connect checkbox to use OAuth 2.0 with OpenID Connect. After selecting the checkbox, enter the URL for the authentication server in the OpenID Connect URL field.

Scriptable request modification

Use a plain text JavaScript file to provide logic that can modify an HTTP request at runtime. Example modifications include changing the request URI, HTTP headers, or the request body. After uploading your JavaScript file to the Veracode Platform, Veracode recommends that you run a prescan to ensure that:

  • Your script is free of errors. The Veracode Platform alerts you to any errors in your script.
  • Your authentication credentials are valid.
  • Veracode can use the script to successfully make requests to the target host.

Veracode provides example scripts for Scriptable Request Modification (SRM).

Add one or more HTTP cookies that the scanner can use to authenticate with the target server. Enter the cookie data in the Cookie field. For example, mycookie=chocolate; To add additional cookies, click Add Another.