Platform of Trust Platform Design Guide
Developer PortalAPI DocsOntology
  • Purpose and scope
  • Developer eXperience Strategy
  • Suggest changes
  • API Requests
    • Request validation
    • Response codes used
    • Error handling
  • General API guidelines
    • Performance
    • Documentation
    • Data models used
    • Use HATEOAS
    • Use HTTP Methods
    • Dates and time
    • Naming conventions
    • Pagination, partial response and sorting
    • API Testing
  • API Headers
    • Mandatory elements & behaviour
    • Rate limiting information
  • API Security
    • Authentication and authorization
    • SSL everywhere - all the time
  • API versioning guidelines
    • Versioning Rules
    • Breaking changes
    • Non-breaking changes example
    • Retirement process
    • Add new API to documentation
    • Add new endpoint
  • API Migration Policies
    • Deprecating API
    • Sunsetting API
    • Blackout Testing
    • Migration Email Template
    • API Blackout Test Email Template
    • API Deprecation Email
    • Deprecating an older API
  • Ontologies
    • About ontologies
    • Web Ontology Language, OWL
    • Ontology editor
    • Edit ontology
    • Add new subclass
    • Naming convention logic
    • Extending the ontology
  • Design Guideline
    • Colors
    • Typography
    • Grids and Space
    • Input forms - Text field
    • Input forms - Text area
    • Buttons
    • Checkbox
    • Radio buttons
    • Date picker
    • Form control - Single select
    • Toggle
    • Pagination
    • Status pills
    • Tables
    • Effects
    • Dialogues
Powered by GitBook
On this page

Was this helpful?

  1. API Security

SSL everywhere - all the time

Always use SSL. No exceptions. Today, your web APIs can get accessed from anywhere there is internet (like libraries, coffee shops, airports among others). Not all of these are secure. Many don't encrypt communications at all, allowing for easy eavesdropping or impersonation if authentication credentials are hijacked.

Another advantage of always using SSL is that guaranteed encrypted communications simplifies authentication efforts - you can get away with simple access tokens instead of having to sign each API request.

One thing to watch out for is non-SSL access to API URLs. Do not redirect these to their SSL counterparts. Throw a hard error instead! The last thing you want is for poorly configured clients to send requests to an unencrypted endpoint, just to be silently redirected to the actual encrypted endpoint.

PreviousAuthentication and authorizationNextVersioning Rules

Last updated 6 years ago

Was this helpful?