Secure API & Backend Engineering
Backend and API systems engineered around the authorisation model rather than around the endpoints — with schema validation, rate limiting, idempotent workflows and audit logging that make abuse expensive and incidents reconstructible.
Verified Solvex Specialist
Verified by SolvexDirect specialist contact for Solvex engagements
What this means. An authorized Solvex administrator registered and approved this exact public identity. What it does not. Solvex has not inspected the account on the platform, and this is not the platform's own verification.
Solvex specialists never ask for your passwords, recovery phrases, one-time codes, or payments to a personal account. Work, scope and invoices are agreed in writing through the official channels on this site.
What's covered
- API architecture and contract design (REST, or GraphQL where it fits)
- Authentication and a explicit authorisation model enforced server-side
- Schema validation on every boundary, with typed contracts end to end
- Rate limiting, quota and abuse-resistance design
- Idempotency for payment, webhook and retry-prone workflows
- Database architecture, migration strategy and access boundaries
- Background jobs and queues with tenant and permission context preserved
- Audit logging, observability and deployment pipeline
What you receive
- Backend source with API contract documentation
- Authorisation model documented as a matrix, not as prose
- Validation and rate-limiting configuration
- Idempotency and retry design for critical workflows
- Audit logging and observability setup
- Deployment pipeline, runbook and handover documentation
Evidence and reporting
How the work is kept honest- Evidence, frozen at issuanceFindings tie to something observed. When the report is issued, the evidence behind it is frozen in the same transaction and cannot be edited afterwards.
- A signed reportAn Ed25519 signature covers both the report content and the delivered file. Alter a byte of either and verification fails.
- Written scope firstAdvisory work runs to a written scope agreed before it starts, so what you receive is what was agreed.
Anyone holding a Solvex report can verify it publicly without seeing its contents.
Our boundaries
What this engagement does not do, stated before it starts.
- Frontend application work is scoped separately unless included
- Third-party API availability and behaviour remain the vendor's responsibility
- Load testing at production scale is a separate engagement
- Infrastructure hosting costs are yours and are not resold by us
How this engagement runs
- 01
Intake
Tell us the system, the goal and the constraints. If the work is not a good fit, we say so before anyone is invoiced.
- 02
Scope and authorization
Written scope and signed authorization before anything is touched. Security testing runs only against systems you own or are contractually entitled to have tested.
- 03
Investigation or build
Specialists matched to the work. Findings are proven by hand — scanner output is a lead, never a finding.
- 04
Evidence
Every finding ties to something observed. When a report is issued, its evidence is frozen in the same transaction, so what backed the report cannot change afterwards.
- 05
Delivery
A signed report: an Ed25519 signature over both the content and the file, with a short verification reference you can read down a phone.
- 06
Verification and retest
Anyone holding the report can verify it publicly without seeing its contents. Fixes are retested as part of the engagement — “fixed” means we confirmed it.
Questions we are asked
- What actually goes wrong in most API breaches?
- Authorisation, overwhelmingly. Not missing authentication — the caller is usually logged in as somebody. The failure is that the endpoint checks who you are and never checks whether this particular object is yours. That is why we start from the authorisation model rather than the endpoint list.
- REST or GraphQL?
- REST unless something specific argues for GraphQL. GraphQL moves query shaping to the client, which is genuinely useful and also makes authorisation, depth limiting and rate limiting materially harder. We will recommend it when it earns its complexity.
- Why does idempotency keep coming up?
- Because networks retry. Without an idempotency strategy a duplicated webhook charges a customer twice, a retried request creates two orders, and reconciliation becomes archaeology. It is a small design decision that prevents a whole class of expensive incidents.
Related services
Engineering
Secure SaaS & Full-Stack Product Engineering
Multi-tenant SaaS built on Next.js, TypeScript and Postgres with the parts that are painful to retrofit — tenant isolation, RBAC, audit trails and billing boundaries — designed in from the schema upward.
Offensive / Testing
API Penetration Testing
APIs are where modern breaches happen. We test your REST, GraphQL and gRPC endpoints for broken authorisation, data leakage and logic flaws, so the interfaces powering your apps and partners can't be turned against you.
Cloud / DevSecOps
Cloud Security Posture Management (CSPM)
Cloud environments drift into risk one change at a time. We assess and help you continuously manage your cloud security posture — catching misconfigurations, compliance gaps and risky changes before they become incidents.