Standards and regulations

42Crunch API Security Platform helps to align your APIs with many of the key security standards, regulations, and recommendations that abound in the modern service industries. This page provides more details on some of them.

OpenAPI Specification

The OpenAPI Specification (OAS) is a standard open source interface description for REST APIs. It is programming language-agnostic and both human and machine readable. Any API consumer can understand what a web application or service can do and interact with it without accessing the source code, additional documentation, or inspecting network traffic.

The OAS is a community-driven specification maintained and developed by the OpenAPI Initiative (OAI). This is a collaborative open source project under Linux Foundation, and 42Crunch is actively participating in the project. The founding companies include such big names as Google, IBM, and Microsoft, and SmartBear Software donated their Swagger Specification to the OAI as the basis for OAS. The variety in participants has helped to keep the description format vendor neutral.

Formerly known as Swagger specification, the OAS has emerged as a widely adopted way of documenting REST APIs. It offers a standard format with large tooling support. Instead of trying to deduce the intent of an API from its behavior or source code, the standard OpenAPI contract makes it easier to communicate this clearly.

One of the key functions that the standard contract can enable is API security, because it provides a way for developers, operations, and security people across teams to speak in common language. When all teams building both the API and the infrastructure the API is going to sit in can clearly communicate the intent, requirements, and outcome, it is also easier and more reliable to uncover, understand, and mitigate security risks. This idea is in the core of 42Crunch Platform.

The OAS allows to clearly specify a contract, the terms and conditions of using the API and the functions it offers. This contract takes the form of an OpenAPI definition, which describes among other things:

  • The functions (operations) that the API offers
  • The data that the API requires or accepts as input for each function
  • The data that the API returns as a response to calling a particular function
  • The security measures protecting the API
  • The linking and connections that the API has to other APIs

The OAS enables developing and utilizing various tools throughout your API's life cycle, such as:

  • Automatically generated API documentation
  • Testing tools
  • Code generation tools for generating servers and clients
  • API firewalls and firewall rules to protect API infrastructure

The OAS does not require completely rewriting your existing APIs, or binding any software to your service. You simply describe the capabilities of the service as the OAS specifies.

OAS versions

There are currently three versions of the OpenAPI Specification that have significant differences between them:

  • version 2
  • version 3.0.x
  • version 3.1.x

The following table summarises some of the key differences between the OAS v2 and v3.0.x:

Feature OAS v2 OAS v3.0.x
Specification and versioning
  • Specification version defined in swagger
  • Specification version defined in openapi
URLs
  • URLs compiled from host, basePath, and schemes
  • Only one API endpoint URL, multiple schemes allowed
  • URLs defined in a dedicated url object
  • Multiple URLs allowed
Paths and methods
  • GET and DELETE can take a request body
  • TRACE not supported
  • Request body no longer allowed for GET and DELETE
  • TRACE supported
Object definitions
  • Parameters and response headers can be defined as object in their own right
  • Cookie parameters not supported
  • MIME types defined in consumes and produces
  • Parameters and response headers must be defined with schemas
  • Cookie parameters supported
  • body and formData replaced by requestBody
  • consumes and produces replaced by content, support for wildcards for mediatypes
  • Support for content type negotiation
  • Callbacks and links as new object types
Combining operations and additional properties
  • oneOf and anyOf not supported
  • additionalProperties as Boolean not supported
  • All combining operations supported
  • additionalProperties as Boolean supported
  • additionalProperties defaults to true, must be explicitly declared as false if a schema must not accept additional properties
Reusable objects
  • Defined under definitions
  • Limited range of reusable components
  • Defined under components
  • More types of reusable components
Security
  • Security schemes defined under securityDefinitions
  • OIDC not supported
  • Cookie authentication not supported
  • securityDefinitions removed
  • OIDC supported
  • Cookie authentication supported
  • Renamed and restructured OAuth2 flows
  • basic renamed to http
Examples
  • Only JSON or YAML objects supported
  • In addition to JSON or YAML objects, examples can also be described as JSON strings
  • Reusable examples object

The following table summarises some of the key differences between the OAS v3.0.x and v3.1.x:

Feature OAS v3.0.x OAS v3.1.x
Specification and versioning
  • Semantic versioning
  • Focused on REST APIs
  • Semantic versioning dropped
  • $schema keyword at the root of the API definition allows specifying the meta-schema for validating the OAS
Webhooks
  • Webhooks not natively supported
  • Paths mandatory
  • Support for webhooks
  • Paths optional if webhooks used
Object definitions
  • Improved but partial or modified JSON Schema support
    • Object type null not supported, the property nullable as a workaround
    • type cannot be an array
    • Properties cannot appear alongside $ref
  • Full support for JSON Schema Draft 2020-12
    • Object type null supported, nullable deprecated
    • Support for arrays in type
    • Other properties can be defined alongside $ref
    • Support for $defs for reusable schema definitions
Combining operations and additional properties
  • Problems with additionalProperties behavior in composition
    • additionalProperties: false can conflict with composition using combining operations
    • additionalProperties: true allows any additional properties
  • Improved composition
    • unevaluatedProperties excludes properties not defined in any of the subschemas composing the final object, works seamlessly with combining operations
Security
  • mTLS not natively supported
    • x-42c-mtls as a workaround
  • Only OAuth 2.0 schemes allow more granular authorization through scopes
  • mTLS supported
    • x-42c-mtls must not be used
  • All security requirements support defining an array of required roles for more granular authorization
Examples
  • examples object for reusable examples
  • Singular example keyword for providing individual examples
  • examples keyword for providing examples, can include arrays of multiple examples
  • Singular example keyword deprecated
  • #components/examples retained for reusable objects

OWASP

The Open Web Application Security Project (OWASP) is a non-profit online community that has long been recognized as an international and industry-standard authority in application security. The community produces articles, methodologies, documentation, tools, and technologies to improve application security. Employing a collaborative and open-source approach, OWASP is dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. It also provides forums open to anyone interested in application security and how to improve it.

For application security, OWASP has long produced its OWASP Top 10 project, an awareness document created in collaboration with a variety of security experts from around the world. The document aims to raise awareness about application security and describes the widely agreed most critical security risks to web applications and through them to organizations. OWASP Top 10 is widely referenced by standards, books, tools, and other organizations.

In addition to the OWASP Top 10 project, OWASP organization also produces OWASP API Security Top 10. Now in its second installment (2019 and 2023), OWASP API Security Top 10 ranks the widely agreed most critical security risks that are specific to REST APIs. As already stated, this is crucial because the nature of APIs and their security considerations are so very different from the traditional applications.

Financial-grade API

The OpenID Foundation Financial API working group is developing Financial-grade API (FAPI), an OAuth-protected REST/JSON model for financial APIs. The working group aims to provide JSON data schemas, protocols, security, and privacy recommendations for concerns such as:

  • How applications can use the data from a financial account of a user
  • How applications interact with the financial account
  • How users can control their security and privacy settings

Financial APIs are at the heart of the financial technology (fintech) field that applies technology to improve financial activities. Companies are vying to develop innovative applications for different platforms that people can use to access the financial services wherever, whenever. These services can include, for example:

  • Online banking
  • Online payments in webshops
  • Currency conversions
  • Credit rating calculations
  • Investment services
  • Stock market monitoring

Some financial information that the services tap into is public, like currency rates. Other operations deal with highly sensitive and private data. This makes watertight security the paramount consideration.

Although FAPI has financial services in its focus, fintech is not the only field that can benefit from FAPI. Their security profiles are not specific to financial APIs, but could be applied to any APIs with similar requirements in relation to potential risks and the sensitivity of the manipulated data.

Payment Services Directive

The revised Payment Services Directive (PSD2) is a requirement for all payment account providers in the European Union. The directive requires banks to open their infrastructures to other service providers through open APIs while making sure that sensitive information stays secure.

Unlike Open Banking (see below), PSD2 does not entail an API standard, but it does provide the legal framework with which other standards must comply.

Open Banking

As a result of PSD2, Open Banking is a UK initiative to use open APIs and open source technology in the financial industry, and share data in a secure and standardized form. Banks must establish APIs to share the financial data they control. This in turn helps developing new applications and services for financial services, and provides more transparency to customers on the financial options available to them.

The Open Banking Standards define how financial data is created, shared, or accessed. Financial customers can securely share their data with the services they want to without having to share their banking login credentials. The data is encrypted and its usage is tracked, and customers can limit in what way and for how long that data can be used. Only regulated companies can participate in Open Banking, and all involved entities must comply with data protection laws.

Open Banking Standard is developed and maintained by Open Banking Implementation Entity (OBIE).

What is...

42Crunch API Security Platform