Skip to content
Octo × Back end and APIs PT Request an assessment

Octo for back end and APIs · dev and security arms

Every endpoint checks who is asking and for what.

The OpenAPI Specification, now at version 3.2.1, describes HTTP APIs in a standard, language-agnostic way. The top risk in the OWASP API Security Top 10 2023 is broken object-level authorization. Two Octo arms work at this step: development codes the endpoint on the branch, with parameterized queries and object ownership checks, and security looks for routes without checks. The API contract and the merge belong to the tech lead.

The OpenAPI contract, the approved plan and the access roles go into Octo, which returns the endpoint on the branch and the list of routes without checks. INPUT OPENAPI CONTRACT APPROVED PLAN ACCESS ROLES ENDPOINT ON THE BRANCH ROUTES WITHOUT CHECKS route → object ownership → parameterized query OCTO × SOFTWARE BACK END ES-04
ArmsDev and securitywork at this step
OpenAPI3.2.1from Sep 10, 2026
Sources5listed at the end of the page
01

What Octo does in the back end.

Four possible deliverables. The contract, the version and the merge are the tech lead's decisions.

Endpoint on the branch

The development arm codes the endpoint following the approved plan, with parameterized queries and object authorization checks in every function that receives an identifier from the user.

Deliverable: code on the task branch

OpenAPI contract alongside the code

Keeps the API's OpenAPI description next to the code, to serve as documentation and as the basis for contract tests.

Deliverable: updated OpenAPI description

Routes without checks

The security arm goes through the routes and flags those that don't check the role or object ownership.

Deliverable: list of routes with the finding for each

Contract changes flagged

When a change breaks API compatibility, the plan says so up front, so the team can decide on the version.

Deliverable: breaking change notice
02

Eight arms, one API.

The same Octo cycle, applied to this step. Each arm has a narrow role; your company's tech lead is in charge and approves.

  1. Discovery

    Maps the routes

    Which endpoints exist, who calls each one and which path the request takes.

  2. Data

    Reads the queries

    Which tables each endpoint queries and how it builds the SQL today.

  3. Security

    Looks for routes without checks

    Role, object ownership and what happens when the identifier belongs to someone else.

  4. Architecture

    Plans the contract

    Routes, parameters, responses and whether the change breaks existing API consumers.

  5. Development

    Codes the endpoint

    Parameterized queries, object checks and the OpenAPI contract alongside.

  6. Review

    Tests through the real path

    A real request, with the least-privileged role and with someone else's identifier.

  7. Release

    Publishes with your OK

    The endpoint only goes to production with the approval of whoever is in charge.

  8. Documentation

    Records the contract

    The OpenAPI description and the version decision are recorded.

Octo codes and checks; the tech lead approves the API contract, decides on breaking changes and the version, and merges.

03

What Octo checks on every endpoint.

Reference risks and rules. The OWASP publications and the specification remain the reference.

Risk or ruleWhat Octo checksBasis
API1:2023, object-level authorizationObject check in every function that receives a user IDOWASP API Security Top 10 2023
SQL injectionParameterized queries; escaping is no substituteOWASP, SQL Injection Prevention
ContractOpenAPI description alongside the codeOpenAPI 3.2.1
Breaking changeNotice up front, to bump the MAJOR versionSemVer 2.0.0
04

From request to routine.

Three steps. Each one only makes sense once the previous one has shown results on your team.

A proposal, not a promise

1 Today

Routes checked

Octo goes through the existing routes and lists those that don't check role or object.

  • List of routes with findings
  • Testing with someone else's identifier
Benefit: the most common API risk becomes visible
2 Next

New endpoints with a contract

Every new endpoint ships with its OpenAPI description and the object check.

  • Contract alongside the code
  • Parameterized query
Benefit: API consumers know what to expect
3 Later

Contract tests

The OpenAPI description now feeds tests that compare design and implementation.

  • Contract checked on every delivery
  • Version flagged on breaking changes
Benefit: the API doesn't change by accident
05

Confirmed by source.

Each point below has a source published by the organization responsible for the standard, the specification or the tool, or in Brazilian federal law. The sources are in the next section.

8

points with a published source, each with its reference alongside.

ConfirmedOpenAPI 3.2.1
The current version of the OpenAPI Specification is 3.2.1, from September 10, 2026.Source: OpenAPI Initiative, OAS 3.2.1
ConfirmedWhat the OAS defines
The OpenAPI Specification defines a standard, language-agnostic interface for HTTP APIs.Source: OpenAPI Initiative, OAS 3.2.1
ConfirmedUses of the description
The OpenAPI description serves documentation portals, code generation, contract tests that check whether design and implementation match, and API-first design.Source: OpenAPI Initiative, what is OpenAPI
ConfirmedTop API risk
The top risk in the OWASP API Security Top 10 2023 is broken object-level authorization (API1:2023).Source: OWASP, API Security Top 10 2023
ConfirmedCheck in every function
Object-level authorization checks should be considered in every function that accesses a data source using an identifier from the user.Source: OWASP, API Security Top 10 2023
ConfirmedParameterized query
The primary defense against SQL injection is prepared statements with parameters; escaping input is strongly discouraged.Source: OWASP, SQL Injection Prevention Cheat Sheet
ConfirmedValidation isn't enough
Validating a value doesn't make it safe to concatenate into SQL.Source: OWASP, SQL Injection Prevention Cheat Sheet
ConfirmedMAJOR version
In SemVer 2.0.0, the MAJOR version goes up when the API changes in an incompatible way.Source: SemVer 2.0.0
06

What Octo does and what stays with you.

Octo prepares everything, but does not sign. The document of record stays with whoever is accountable for it.

Octo prepares

Maps, plans, codes on the task branch, reviews with evidence and prepares the release: plans, code, reviews, security reports and the system dossier.

Deliverable: material ready for review

Your team reviews

Whoever is in charge is the company's tech lead or senior developer: they approve the plan, review the PR and merge it. Nothing goes to production without their approval.

Step: approval by whoever is in charge

Who signs and is accountable

Octo does not sign and is not accountable for the system. The tech lead accepts the risk and is accountable for the system in production; a security report or opinion is signed by a professional at the company.

Accountable: the company's tech lead
07

Sources.

OpenAPI Initiative, OWASP and the SemVer specification. Accessed October 31, 2026.

Endpoints that check who is asking.

The assessment starts with the routes you already have, without changing anything. You get the list of what still needs checking and decide with it in hand.