acAbderrahmane
Chafik

Abderrahmane Chafik

ENSAM Casablanca · Expected graduation 2027
Available for PFE · February 20275–6 months

Cybersecurity & Cloud · Engineering student

Engineeringtrust.

From the first API request to the cloud it runs on. I build security controls that can be understood, tested and repeated.

01API security

Identity is only the beginning. Authorization defines what comes next.

02Cloud boundaries

A public entry point does not need to mean public infrastructure.

03Security automation

A control becomes more useful when it can be checked again.

CONNECTION / BOUNDARY / CONTROL

Selectedinvestigations.

Four ways to turn a security question into something concrete.

01Question the boundary
02Build the control
03Read the evidence
/01API SECURITY / AUTOMATION

CyberScope

Turning API security questions into reusable, automated checks.

The engineering question

An API can return a valid response while exposing the wrong resource. How do you make authentication, authorization and input handling repeatable parts of the engineering workflow?

The implementation

A reusable API security testing framework, with Robot Framework suites, Python helpers and Jenkins integration. A local FastAPI demonstration API provides a controlled setting for developing the checks.

Robot FrameworkPythonOpenAPIJenkinsFastAPI
A closer look / API authorization

One request.Three questions.

Illustrative test design · not an execution result

01 / Set the context
Who is asking?

Configure two test identities. Knowing who made a request is the starting point — not proof that they should access every object.

TEST_USER_ID_SELF / TEST_USER_ID_OTHER
02 / Test the boundary
What should they access?

Request another identity’s resource with the configured account. The endpoint and test data must support this scenario.

BOLA / Broken Object Level Authorization
03 / Read the evidence
What does the response prove?

Review response behavior against the expected access policy. HTML and JSON reports make the check inspectable; an HTTP success alone does not prove correct authorization.

HTML / JSON reports · Jenkins
Expected policy
Configured access boundary
Observed response
Compare with the policy
Report artifact
HTML + JSON evidence
Based on the documented BOLA configurationREADME.md ↗

From idea to implementation

01
Configure the target

Set the base URL, authentication strategy and relevant test identities. OpenAPI-driven discovery helps adapt the suite to the API.

02
Exercise the boundaries

Documented checks cover authentication enforcement, BOLA, malformed inputs, information disclosure and rate limiting. Advanced checks depend on the target configuration.

03
Read the evidence

Jenkins orchestration and HTML / JSON reporting connect test execution to reviewable findings.

What you can inspect

What you can inspect

Illustrative test design from the documented BOLA configuration. No execution result is shown.

The useful question is not “did the API respond?” It is “should this identity have access?”

Boundaries & lessons

This is a testing toolkit, not a guarantee that an API is secure. BOLA needs appropriate identities and endpoints; optional checks may be skipped. Repository coverage and performance claims have not been independently validated.

/02CLOUD SECURITY / INFRASTRUCTURE AS CODE

CloudSec-Lab

An AWS lab built around private networking, scoped identity and reviewable infrastructure.

The engineering question

Cloud security depends on how networking, identity and visibility fit together. How can those decisions be made explicit, reproducible and easy to review?

The implementation

A portfolio lab combining modular Terraform infrastructure with a small FastAPI application, hardened Docker configuration and automated security validation workflows.

AWSTerraformIAMDockerGitHub ActionsCheckovTrivyGitleaks
Engineering sequence01 / 03

Illustrative system study · not a live execution

01 / From idea to implementation

Separate public and private

A public ALB fronts optional application instances in private subnets. Security-group references restrict backend access; there is no public instance IP or SSH ingress.

02 / From idea to implementation

Scope identity and preserve evidence

IAM roles, IMDSv2 and branch-bound OIDC trust are paired with CloudTrail, an encrypted private S3 audit bucket, CloudWatch and configurable GuardDuty.

03 / From idea to implementation

Validate before deployment

Terraform validation, IaC and secret scanning, application checks and container scanning are documented as separate CI gates. Compute and NAT are disabled by default.

What you can inspect

Public entry. Private compute.

Reconstructed architecture decision from the repository documentation; not a deployed environment.

INTERNET → ALB
One public entry point

The Application Load Balancer sits in public subnets.

ALB → APPLICATION
Reference the source

Application security groups accept traffic from the ALB security group, rather than a broad public range.

APPLICATION → ADMIN
Remove direct entry

Optional EC2 instances use private subnets, no public IP and no inbound SSH. Compute and NAT are disabled by default.

The boundary is expressed in infrastructure code, so a reviewer can inspect who can reach the application before deployment.

Boundaries & lessons

An educational lab, with no verified production deployment. HTTPS, VPC endpoints and a deliberately scoped deployment policy remain future work. AWS resources incur costs; CI validation does not deploy them. Private compute also needs a controlled software-delivery path.

/03DEFENSIVE SECURITY / WEB APPLICATIONS

Bastion-WAF

A hands-on study of request inspection, from established rules to a custom Python WAF.

The engineering question

A firewall rule is easier to trust when you understand what it sees. What does request inspection actually do between a client and a vulnerable application?

The implementation

A multi-layer WAF laboratory: a custom Python reverse proxy with YAML signatures and JSONL blocked-request logs, alongside ModSecurity / OWASP CRS on Nginx and a DVWA target.

PythonYAMLNginxModSecurityOWASP CRSDocker
Engineering sequence01 / 03

Illustrative system study · not a live execution

01 / From idea to implementation

Observe the request path

Docker Compose connects the vulnerable target, open-source WAF and custom reverse proxy in a dedicated lab network.

02 / From idea to implementation

Inspect and decide

The custom engine applies detection rules with a configurable anomaly threshold. Detection-only and blocking modes distinguish observation from enforcement in the main inspection path.

03 / From idea to implementation

Compare the defenses

SQL injection and XSS examples support repeatable lab exercises. A documented dashboard and engineering report help compare the custom approach with established WAF systems.

What you can inspect

Observe first. Enforce deliberately.

Configuration checked against the README and inspection code. These are documented settings, not measured protection results.

UPSTREAM_URL
Choose the protected target

Points the reverse proxy at the application being protected in the lab.

ANOMALY_THRESHOLD = 5
Tune the decision boundary

The documented default threshold is configurable. Tuning changes how the WAF responds to detected anomalies.

WAF_MODE
Separate detection from blocking

In the main inspection path, detection-only logs threshold violations; blocking returns HTTP 403 for them. Separate rate-limit and binary-header checks can still block in either mode.

A defensive rule needs context: the target, the threshold and the enforcement mode all affect its behavior.

Boundaries & lessons

A defensive learning environment, not a production security product. No independent benchmark establishes throughput or detection completeness. Rate limiting and binary-asset header checks can still block in detection-only mode. DVWA is intentionally vulnerable and belongs in an isolated, authorized laboratory.

/04CYBERSECURITY LEARNING / LOCAL AI

CyberGuide-AI

A CTF learning platform that brings guided practice and a local AI mentor together.

The engineering question

Security learning needs room to investigate, not just an answer. How can a local assistant support a learner while challenges and progress remain part of one experience?

The implementation

A school project combining CTF challenges and an Ollama-backed mentor with a FastAPI backend. The repository documents frontend, backend and AI roles without a verified individual allocation; this study describes the project implementation.

FastAPIPythonOllamaJWTSQLiteWebSocketDocker
Engineering sequence01 / 03

Illustrative system study · not a live execution

01 / From idea to implementation

Practice in context

Accounts, challenge tracking, flag submission and writeups keep the learning journey connected. SQLite persists user and challenge data.

02 / From idea to implementation

Ask a local mentor

Ollama provides local model inference. Prompt and walkthrough files guide the assistant; the model is configurable.

03 / From idea to implementation

Connect the platform

JWT authentication and admin checks sit alongside competition events and a WebSocket leaderboard. Docker Compose brings the application and local model service together.

What you can inspect

A hint is a step, not the finish line.

Illustrative learning journey assembled from documented features. This is not a screenshot or a generated chat transcript.

01 / GUIDANCE
Ask the local mentor

The FastAPI application connects to Ollama for local model inference and guided hints.

02 / PRACTICE
Work through the challenge

The learner investigates a CTF challenge and submits a flag. No fabricated answer or success rate is shown here.

03 / REFLECTION
Keep the learning trail

Persistent progress tracking and writeups support revisiting the work; WebSocket updates serve the live leaderboard.

AI supports the learning process. The platform still separates guidance, challenge submissions and recorded progress.

Boundaries & lessons

A school learning platform with no verified production deployment. The first registered account becomes administrator; chat sessions use in-process memory. README model defaults differ between sections, so no fixed model is claimed here. Local inference quality and resource needs depend on the chosen model.

Curiosity is the start.Method makes it useful.

I’m Abderrahmane, a Cybersecurity & Cloud Computing engineering student at ENSAM Casablanca, expected to graduate in 2027. I like understanding what happens between a request and a response — and where trust can break along the way.

My work connects application security, infrastructure and automation. Through labs and internships, I turn security questions into controls that can be inspected, tested and improved.

01

Understand

Map the system and its trust boundaries.

02

Build

Translate a security idea into a concrete control.

03

Validate

Make checks repeatable and evidence readable.

How I turn a question into engineering.

01

Start with the boundary.

In CloudSec-Lab, the public entry point and private application belong to different trust zones. I make that distinction explicit in the infrastructure.

CloudSec-Lab ↗
02

Make the behavior inspectable.

CyberScope turns authorization questions into configured checks and reviewable reports. Bastion-WAF explores what changes between observing a request and enforcing a rule.

CyberScope + Bastion-WAF ↗
03

Keep learning in the loop.

CyberGuide-AI connects local model guidance with CTF practice. I am interested in tools that help explain a system, as well as test it.

CyberGuide-AI ↗

Areas of practice

01

Application & API security

Authentication, authorization, BOLA, input validation, OAuth2 / OIDC and defensive web controls.

↗
02

Cloud & infrastructure

AWS, Terraform, IAM, network segmentation, audit trails and container hardening.

↗
03

Automation & secure software

Python, Robot Framework, Jenkins, GitHub Actions, FastAPI, Java / Spring and local LLM integration.

↗

Learning through practice.

Aug–Sep 2026
XELOPS Technology

Network Architecture & Cybersecurity Intern

Reviewed segmentation, VLAN isolation, firewall / ACL policies and administrative access. Produced security recommendations and target architecture documentation.

Jan–Feb 2026
XELOPS Technology

API Security Automation Intern

Built reusable API security tests and integrated them with Jenkins. Used OpenAPI specifications to adapt scenarios to target APIs.

Jun–Jul 2025
Munisys

Cybersecurity & Cloud Intern

Analyzed information-system risks and designed a Microsoft 365 email-security solution, including a technical study of Trend Micro Vision One — Email Protection.

Jun–Aug 2023
Bigzone

Test Automation Intern

Created functional and regression test scenarios with Robot Framework and Selenium.

Aug–Sep 2022
Bigzone

Software Testing Intern

Prepared and executed functional tests, documented defects and verified corrections.

Education

ENSAM Casablanca

Engineering · Cybersecurity & Cloud Computing

2022–2027 · Expected graduation 2027
2027

Credentials & continued learning

✓ Completed

AWS Academy Graduate — Cloud Security Foundations

Training badge
✓ Completed

Google Cybersecurity Professional Certificate

Professional certificate
✓ Completed

Cisco Networking Academy — Cybersecurity Essentials

Training
✓ Completed

Splunk — Intro to Splunk

Training
✓ Completed

Red Hat — Introduction to Python Programming (AD141)

Training
✓ Completed

Cisco Networking Academy — Introduction to Cybersecurity

Training
↗ In progress

Fortinet — FortiGate 7.4 Administrator

Training