Users are responsible for maintaining and monitoring the usage of their own API key(s). The following document is provided as an illustration of areas developers may wish to consider and should not be considered formal Guidance. Majestic does not offer security consultancy to end users or third party developers.
In order to provide legacy compatibility and provide the widest range of options, in keeping with industry practice, the Majestic API supports a range of access methods. Developers should familiarise themselves with the risk profile of these methods and determine the most appropriate access method for their context.
Majestic supports endpoints via both http and https. The risks associated with sending requests without transport layer security are well documented. Many modern programming languages support both http and https with very little overhead in terms of developer time. HTTP is supported for legacy reasons and should be considered deprecated.
In keeping with many players in the industry, Majestic supports both POST and GET request methods for API calls. HTTPS POST removes the need to pass parameters in the URL, reducing the opportunity for interception.
HTTPS GET should not be considered to offer the same level of security as HTTPS post. Whilst many developers use GET requests when debugging or investigating aspects of web based APIs, it should be noted that some browser plugins have send the URLs entered to third party servers, where such data may be made publically available via Web traffic reporting services.
As developer use of GET is considered a common use case, the Majestic API supports the passing of app_api_key as a cookie in order to avoid the need to pass this sensitive data where it may be intercepted. To limit potential for confusion, Cookie based authentication is only supported for HTTP(S) GET, and only when the app_api_key is not passed as a URL parameter.
API keys are only as secure as the context in which they are used. In order to use them, one or more members of staff need to have access to them. In addition to technical compromise, malicious or accidental compromise of API keys may be considered as a part of a wider IT strategy. It is therefore important for API key users to monitor the usage of the API and to consider appropriate key management strategies.
The API Key Management page is the hub for Majestic API management. The Majestic API supports multiple keys, which may help support a key management process – such as providing one key for development and another for a live environment, or potentially to re-issue keys when developers leave your organisation. It is possible to enable or disable access on a per key basis, and multiple keys may be enabled at once – facilitating higher availability during product release or upgrade.
The Majestic API supports the limiting of API access to a number or range of IP addresses on a per key basis. Whitelisted IPs may be expressed as individual IPv4 Addresses, or alternatively ranges of IPs may be listed in CIDR notation ( e.g 192.168.100.14/24 ). A white list policy may contain a combination of IP addresses and/or CIDR notation ranges. An absence of any whitelisted addresses will cause the API key to be open to access from all IP addresses.
The API command GetSubscriptionInfo ( http://developer-support.majestic.com/api/commands/get-subscription-info.shtml ) and My Subscriptions page ( https://majestic.com/account/my-subscriptions ) provide headline resource usage statistics. In addition, the API activity page in the API Management console provides a more detailed view of API usage on a key and IP address basis.
For more information about access to the Majestic API suite, visit our Plans & Pricing page.