GGKP Knowledge Brokerage API
Home
What is GGKP?
Home
What is GGKP?
  1. Home
  • Overview
  • Use Cases
  • Security
  • FAQ
  • Taxonomy
    • Retrieve Master Taxonomy
      GET
    • Retrieve Taxonomy by Term ID
      GET
    • Retrieve Domain-Specific Taxonomy
      GET
  • Search
    • Federated Search
      POST
    • Semantic Search
      POST
    • List Connected Sources
      GET
    • Register New Source
      POST
    • Upload Knowledge Products
      POST
    • List Products by Source
      GET
    • Delete Products
      DELETE
  • Classifier
    • Classify PDF Document
      POST
    • Generate Body and Summary
      POST
  • Bots
    • Generic Bot
      POST
  1. Home

Security

The GGKP Knowledge Brokerage API is built on a Drupal-based REST architecture, chosen in part for its mature, enterprise-grade security framework. The security model operates across five distinct layers, each addressing a different class of risk. Together, they provide defence in depth: no single control is the sole barrier against unauthorised access or misuse.

1. Secure Authentication#

Authentication is the outermost layer of access control. All API credentials are validated at the gateway before any service logic executes, and all communication is encrypted in transit. It is based on the issuing of an API KEY.
Important — API keys must be treated as secrets. Store them in environment variables or a secrets manager. Never commit keys to source code, client-side assets, or version control.

2. Role-Based Access Control#

Once authenticated, the platform applies role-based access control (RBAC) to determine what an authenticated client is permitted to do. Access is enforced at the endpoint level and, where applicable, at the content type and field level.
Key properties of the RBAC model:
Each operation requires an explicit permission grant — there is no implicit access
Read, create, update, and delete permissions are independently assignable
Permission scope is fixed at key issuance and cannot be elevated at runtime
A partner with upload rights cannot delete products registered by another source
Permission reference:
PermissionRequired For
Upload SourcePOST /search-federator/upload-source
Upload ProductsPOST /search-federator/upload-products
Domain SourcesDomain-scoped source listing and management
List ProductsGET /search-federator/products/{source_id}
Read operations — taxonomy retrieval, search queries, and PDF classification — require only a valid API key with no additional permission grants.

3. Data Exposure Control#

Beyond controlling who can call the API, the platform controls what each call can return. The goal is to expose the minimum data necessary for each operation and eliminate unnecessary attack surface.
Controls in place:
Only explicitly required API endpoints are enabled — unused REST resources are disabled
Field-level restrictions prevent responses from returning data beyond what the operation requires
API responses are scoped to the minimum dataset needed for the requested function
Exposure configuration is reviewed whenever new endpoints or fields are introduced

4. CSRF and Request Protection#

All write operations are protected against cross-site request forgery (CSRF). A valid API key alone is insufficient to execute a write from an unauthorised origin — the request must also carry a valid CSRF token.
Applies to: POST, PATCH, and DELETE operations.
CSRF token validation is enforced at the API gateway, before the request is routed to any service. This prevents malicious cross-site attacks from exploiting authenticated browser sessions.

5. Infrastructure-Level Protection#

Security controls extend beyond the application layer to the infrastructure on which the API runs. These controls address network-level threats, volumetric abuse, and the operational visibility required to detect and respond to anomalous behaviour.
ControlDescription
SSL/TLSHTTPS enforced at the network boundary via SSL certificate
Web Application Firewall (WAF)Filters malformed, malicious, and out-of-policy requests before they reach the application
Rate LimitingPrevents API abuse and protects service availability across all clients
Monitoring & LoggingComprehensive logging of API usage supports anomaly detection, incident response, and audit

Security Summary#

LayerMechanismWhat It Protects Against
AuthenticationAPI key / OAuth 2.0 over HTTPSCredential interception, unauthenticated access
RBACPer-endpoint permission grantsUnauthorised operations by authenticated clients
Data ExposureEndpoint and field restrictionsData leakage, over-broad API responses
CSRF ProtectionToken validation on write operationsCross-site request forgery
InfrastructureWAF, rate limiting, TLS, loggingNetwork attacks, abuse, undetected anomalies
Previous
Use Cases
Next
FAQ
Built with