Skip to main content

Cybersecurity

Security is designed in, not bolted on

Most of the incidents we see come from simple causes: an access right that is too broad, a dependency never updated, a secret left in the code.

The problems we address

What brings you here

Everyone has administrator rights

With no role management, anyone can do anything. A mistake or one compromised account becomes a major incident.

Secrets live in the code

Database passwords and API keys committed to the repository, visible to everyone who has ever worked on it.

Nobody knows who did what

No usable logging. After an incident, reconstructing events is impossible.

Dependencies are never updated

Vulnerabilities that have been known and fixed for months remain exploitable in production.

Deliverables

What you receive

  • Technical audit of applications and infrastructure
  • Hardening of web and mobile applications
  • API protection: authentication, authorisation, rate limiting
  • Identity, role and permission management
  • Encryption of sensitive data at rest and in transit
  • Logging and usable audit trails
  • Hardening of infrastructure and configurations
  • Secret lifecycle management
  • Support on compliance and personal-data protection
  • Training for development teams

Benefits

What it concretely changes

Access reduced to what is needed

Roles defined by actual function, periodic access review, immediate removal when someone leaves.

Incidents that can be reconstructed

A timestamped, tamper-evident audit log of sensitive actions.

Exposure that is measured

The audit produces a list ranked by real risk, not a generic catalogue.

Teams that are trained

Good practice applied to your code, on your cases, not in theory.

Features

What we can do in this area

  • Security-oriented code review
  • Application penetration testing within an authorised scope
  • Systematic server-side input validation
  • Protection against injection, cross-site scripting and request forgery
  • Security and content header policy
  • Rate limiting and anti-automation protection on forms
  • Upload controls: real file type, size, opaque naming
  • Encryption of sensitive integration settings
  • Rotation and revocation of keys and certificates
  • Detection and response: what to do in the first few hours

Our approach

How we go about it

  1. Scope and authorisation

    A written scope, formal authorisation, an agreed testing window. No testing outside that frame.

  2. Reconnaissance

    An inventory of the exposed surface: domains, services, dependencies, accounts.

  3. Analysis

    Configuration review, code review, manual and tool-assisted testing according to scope.

  4. Report

    A report ranked by risk, with a proof of concept and a proposed fix for each point.

  5. Verification

    A re-check after remediation, to confirm that the flaw is genuinely closed.

Architecture

How it is built

We apply least privilege at every layer: one compromised component must not give access to the whole system.

  1. Identity

    Strong authentication, short sessions, attempt limiting, a second factor on sensitive accounts.

  2. Authorisation

    Control by role and by resource, checked on the server at every call — never only in the interface.

  3. Data

    Encryption in transit and at rest, separation by scope, minimisation of what is kept.

  4. Exposure

    Strict CORS policy, security headers, rate limiting, validation of external URLs.

  5. Traceability

    An audit log of sensitive actions, with no confidential data in the logs.

  6. Lifecycle

    Dependency updates, secret rotation, controlled removal of access and equipment.

Technologies

Relevant technologies

  • OWASP ASVS
  • OWASP Top 10
  • TLS / mTLS
  • OpenSSL
  • X.509
  • OAuth 2.0
  • JWT
  • Argon2
  • Nginx
  • Docker
  • Linux
  • Sentry
  • Postman

Frequently asked questions

Frequently asked questions

Cybersecurity

Do you work on systems we do not own?
No. Any engagement requires written authorisation from the system's owner, with a defined scope and window.
Can our developers act on the report?
Yes. Each point sets out how to reproduce it, its real impact and the proposed fix, at the technical level of detail required.
Do you handle regulatory compliance?
We support the technical side: minimisation, encryption, traceability, retention periods, individuals' rights. The legal analysis is for your own counsel.
How often should an audit be repeated?
After every major change, and at least once a year. An audit is a snapshot at one point in time.

Africa Tech Services

A project around “Cybersecurity”?

A first thirty-minute conversation, with no commitment. We will tell you plainly whether we are the right partner — and if not, we will point you elsewhere.