DEV Community: Abel Fernando PACOMPIA ORTIZ

Applying Pytest and Requests for Real-World API Testing in a FastAPI Application

Abel Fernando PACOMPIA ORTIZ — Sat, 27 Jun 2026 07:41:53 +0000

Introduction

API testing is an essential practice for validating backend applications before they are deployed. In this project, I built a small FastAPI application and tested its endpoints using Pytest and FastAPI TestClient. The goal is to show a practical and academic example of how automated API tests can improve reliability.

What is API Testing?

API testing verifies the behavior of application endpoints. Instead of checking visual elements, API tests send HTTP requests and validate status codes, response bodies, data formats, and error handling.

Why API Testing is Important

Modern applications often depend on APIs to connect frontends, services, databases, and external systems. If an API endpoint fails, many parts of the system can be affected. Automated API tests help detect problems early and provide confidence when making changes.

API Testing Frameworks Comparative

Framework	Language / Ecosystem	Best use case	Automation support
Pytest + Requests / TestClient	Python	Developer-friendly automated API tests	Excellent with CI/CD tools
Postman + Newman	JavaScript / CLI ecosystem	Manual and automated API collections	Good for pipeline execution
Rest Assured	Java	API testing in Java projects	Strong with Maven, Gradle, and CI
Karate DSL	Java / DSL	BDD-style API tests with readable scenarios	Good CI/CD integration

Why I Chose Pytest

I chose Pytest because it is simple, readable, and widely used in Python projects. It allows developers to write test functions with plain assertions, and it integrates easily with FastAPI through TestClient.

Demo API with FastAPI

The demo API provides endpoints for a welcome message, health check, listing users, retrieving a user by id, and creating a new user in memory.

Example from app/main.py:

@app.get("/users/{user_id}", response_model=User)
def get_user_by_id(user_id: int) -> User:
    """Return one user by id or a clear 404 error."""
    for user in users:
        if user.id == user_id:
            return user

    raise HTTPException(
        status_code=status.HTTP_404_NOT_FOUND,
        detail=f"User with id {user_id} was not found.",
    )

Writing Real-World API Test Cases

The test suite checks successful responses, response content, list structures, user lookup, error handling, and validation failures.

Example from tests/test_api.py:

def test_health_check_returns_ok():
    # Validates that the health endpoint reports the API as available.
    response = client.get("/health")

    assert response.status_code == 200
    assert response.json() == {"status": "ok"}

Running the Tests Locally

To install dependencies and run the tests:

python -m pip install -r requirements.txt
pytest -v

Automating API Tests with GitHub Actions

GitHub Actions can run the test suite automatically when code is pushed or when a pull request is opened.

Example from .github/workflows/api-tests.yml:

name: API Tests with Pytest

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  api-tests:
    runs-on: ubuntu-latest

Results

The project includes seven API tests that validate the main behavior of the demo application. These tests can be executed locally with Pytest and automatically in GitHub Actions.

Conclusion

Pytest is a strong option for API testing in Python because it is readable, flexible, and easy to automate. Combined with FastAPI and GitHub Actions, it supports a simple but effective workflow for validating backend behavior before deployment.

GitHub Repository Link

GitHub repository: https://github.com/Abel-GG-777/api-testing-pytest-demo.git

Applying Checkov SAST to Detect Security Issues in Terraform Infrastructure as Code

Abel Fernando PACOMPIA ORTIZ — Sat, 27 Jun 2026 05:47:57 +0000

Introduction

Security issues in cloud infrastructure often start as small configuration mistakes. A public network rule, a missing encryption setting, or an overly permissive policy can create serious risk when infrastructure is deployed.

This demo project shows how to use Checkov as a Static Application Security Testing tool for Terraform Infrastructure as Code. The goal is academic and practical: detect insecure Terraform configuration before deploying anything to the cloud.

What is Infrastructure as Code?

Infrastructure as Code, or IaC, is the practice of defining infrastructure using code. Instead of manually creating cloud resources through a web console, teams describe resources in files that can be versioned, reviewed, tested, and automated.

Terraform is one of the most popular IaC tools. It allows teams to define providers, networks, storage, compute resources, permissions, and other infrastructure components using declarative configuration files.

What is SAST for IaC?

Static Application Security Testing normally means analyzing source code without running it. For IaC, the same idea applies to infrastructure definitions. A scanner can inspect Terraform files and identify risky patterns before the infrastructure is created.

This is useful because security feedback arrives earlier in the development lifecycle. Developers and DevOps teams can fix misconfigurations before they become real cloud exposure.

Why Checkov?

Checkov is a static analysis tool designed for Infrastructure as Code. It supports Terraform and can detect issues such as public access, missing encryption, weak network rules, and insecure cloud service configuration.

For this project, Checkov is a good fit because it is simple to run locally, easy to integrate into GitHub Actions, and focused on IaC security scanning.

Vulnerable Terraform demo

The vulnerable Terraform file defines an AWS provider, a security group, and an S3 bucket. The file is intentionally insecure for demonstration purposes only.

One important issue is SSH exposed to the entire internet:

ingress {
  description = "Insecure SSH access from anywhere"
  from_port   = 22
  to_port     = 22
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
}

SSH open to 0.0.0.0/0 is insecure because any public IP address can attempt to connect. This increases the attack surface and can expose servers to brute-force attacks, credential attacks, and unauthorized access attempts.

The vulnerable version also includes fully open outbound traffic:

egress {
  description = "Overly permissive outbound access"
  from_port   = 0
  to_port     = 0
  protocol    = "-1"
  cidr_blocks = ["0.0.0.0/0"]
}

Fully open egress is too permissive because it allows outbound traffic to any destination, using any protocol and port. In a real environment, this can make data exfiltration or unauthorized external communication easier.

The S3 bucket is also basic and does not define extra protections such as public access blocking or explicit encryption:

resource "aws_s3_bucket" "vulnerable_bucket" {
  bucket = "checkov-sast-demo-vulnerable-bucket"
}

Running Checkov locally

Checkov can be installed and executed with Python:

python -m pip install checkov
checkov -d . --framework terraform --skip-path venv
checkov -d . --framework terraform --skip-path venv -o cli > checkov-report.txt

The -d . option tells Checkov to scan the current directory. The -o cli option prints the report in command-line format, and the final command stores the output in a text report.

Explaining findings

Checkov analyzes the Terraform files and compares them with security policies. In this demo, it should identify risky patterns such as public SSH exposure, missing S3 security controls, and overly permissive network configuration.

These findings matter because infrastructure misconfigurations can become real vulnerabilities after deployment. Detecting them statically helps reduce risk before cloud resources exist.

Secure Terraform version

The secure Terraform version restricts SSH to a trusted example IP address:

ingress {
  description = "SSH access from a trusted example IP"
  from_port   = 22
  to_port     = 22
  protocol    = "tcp"
  cidr_blocks = ["203.0.113.10/32"]
}

The 203.0.113.10/32 address is documentation-only example IP space. In a real project, this should be replaced with an approved corporate VPN, bastion host, or administrative IP range.

The secure file also restricts egress to HTTPS:

egress {
  description = "HTTPS outbound access only"
  from_port   = 443
  to_port     = 443
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
}

For S3, the secure version enables public access blocking:

resource "aws_s3_bucket_public_access_block" "secure_bucket_public_access" {
  bucket = aws_s3_bucket.secure_bucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Blocking public access helps prevent accidental exposure of data. This is especially important because S3 buckets are commonly used to store sensitive application, backup, log, or user data.

The secure version also enables server-side encryption:

resource "aws_s3_bucket_server_side_encryption_configuration" "secure_bucket_encryption" {
  bucket = aws_s3_bucket.secure_bucket.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

S3 encryption is a good practice because it protects stored objects at rest. Even when access controls are also required, encryption adds another layer of defense.

GitHub Actions automation

The project includes a GitHub Actions workflow that runs Checkov automatically on pushes and pull requests to the main branch:

name: Checkov IaC SAST Scan

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  checkov:
    name: Run Checkov
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Run Checkov Terraform scan
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          framework: terraform
          output_format: cli
          soft_fail: true

Integrating Checkov into GitHub Actions improves the DevSecOps workflow because every change can be scanned automatically before it is merged. This helps teams detect insecure Terraform code during code review instead of after deployment.

In this academic demo, soft_fail: true is used because the repository intentionally contains vulnerable Terraform code. This setting keeps the pipeline successful while still displaying the security findings in the workflow logs.

Conclusion

This project demonstrates how Checkov can be used to detect security issues in Terraform Infrastructure as Code. The vulnerable version shows common cloud misconfigurations, while the secure version demonstrates safer alternatives.

By combining local scanning with GitHub Actions automation, teams can introduce security checks early and continuously in the CI/CD process.

GitHub repository link placeholder

GitHub repository: https://github.com/Abel-GG-777/checkov-terraform-sast-demo.git

Applying Bandit SAST to Detect Vulnerabilities in a Python Flask Application

Abel Fernando PACOMPIA ORTIZ — Sat, 27 Jun 2026 03:26:12 +0000

Introduction

Security should be part of the development workflow, not only a final checklist before deployment. One practical way to introduce security earlier is by using Static Application Security Testing tools. In this article, I demonstrate how to use Bandit to analyze a small Python Flask application that intentionally contains insecure code.

GitHub repository: https://github.com/Abel-GG-777/bandit-sast-python-demo

What Is SAST?

Static Application Security Testing, commonly called SAST, is a security testing approach that analyzes source code without executing the application. Instead of waiting until runtime, SAST tools inspect code patterns and identify potential vulnerabilities early in the development lifecycle.

SAST is especially useful in academic and professional environments because it can be automated in CI/CD pipelines and used by developers before code is merged.

Why Bandit?

Bandit is a SAST tool designed specifically for Python. It scans Python files and reports common security issues such as hardcoded credentials, unsafe subprocess usage, weak cryptography, and risky configuration.

For this demo, Bandit is a good choice because it is lightweight, easy to install, simple to run from the command line, and easy to integrate with GitHub Actions.

Demo Vulnerable Code Explanation

The demo application is a small Flask project in app.py. It intentionally includes several insecure patterns so Bandit can detect them:

A hardcoded administrator password stored directly in the source code.
A subprocess.check_output call using shell=True.
User input from a query parameter concatenated into a shell command, creating a possible command injection risk.
The use of hashlib.md5, a weak hashing algorithm for security-sensitive use cases.
Flask running with debug=True.

These vulnerabilities are intentionally simple so the results are easy to explain in a classroom or presentation.

Running Bandit Locally

First, install the dependencies:

python -m pip install -r requirements.txt

Then run Bandit against the repository:

python -m bandit -r .

To generate a text report, run:

python -m bandit -r . -f txt -o bandit-report.txt

Explaining Findings

Bandit reports issues with identifiers, severity levels, confidence levels, file paths, and line numbers. In this project, the expected findings are related to hardcoded credentials, subprocess execution, shell usage, MD5 hashing, and debug mode.

The important part of the demo is not only seeing the warnings, but understanding why each pattern is risky. For example, shell=True becomes dangerous when combined with user-controlled input because the shell may interpret special characters as commands.

Secure Code Improvements

The corrected version is implemented in app_secure.py. It applies simple improvements:

The password is loaded from the ADMIN_PASSWORD environment variable.
shell=True is removed.
The subprocess call uses a list of arguments instead of a shell command string.
MD5 is replaced with SHA-256.
Flask debug mode is disabled.

This secure version keeps the application easy to understand while showing how vulnerable patterns can be improved.

GitHub Actions Automation

The repository includes a GitHub Actions workflow at .github/workflows/bandit.yml. It runs on pushes and pull requests targeting the main branch.

The workflow checks out the repository, configures Python 3.11, installs dependencies, and runs:

python -m bandit -r . -f txt

This demonstrates how SAST can become part of a continuous integration process. Every push or pull request can be scanned automatically before changes are accepted.

Conclusion

Bandit is a practical tool for introducing SAST into Python projects. It is simple to run locally, easy to automate, and useful for identifying common insecure coding patterns. This demo shows how a vulnerable Flask application can be scanned, how the findings can be explained, and how a corrected version can reduce the reported risks.

Applying Bandit SAST to Detect Vulnerabilities in a Python Flask Application

Abel Fernando PACOMPIA ORTIZ — Sat, 27 Jun 2026 03:26:12 +0000

Introduction

GitHub repository: https://github.com/Abel-GG-777/bandit-sast-python-demo

What Is SAST?

SAST is especially useful in academic and professional environments because it can be automated in CI/CD pipelines and used by developers before code is merged.

Why Bandit?

For this demo, Bandit is a good choice because it is lightweight, easy to install, simple to run from the command line, and easy to integrate with GitHub Actions.

Demo Vulnerable Code Explanation

The demo application is a small Flask project in app.py. It intentionally includes several insecure patterns so Bandit can detect them:

A hardcoded administrator password stored directly in the source code.
A subprocess.check_output call using shell=True.
User input from a query parameter concatenated into a shell command, creating a possible command injection risk.
The use of hashlib.md5, a weak hashing algorithm for security-sensitive use cases.
Flask running with debug=True.

These vulnerabilities are intentionally simple so the results are easy to explain in a classroom or presentation.

Running Bandit Locally

First, install the dependencies:

python -m pip install -r requirements.txt

Then run Bandit against the repository:

python -m bandit -r .

To generate a text report, run:

python -m bandit -r . -f txt -o bandit-report.txt

Explaining Findings

Secure Code Improvements

The corrected version is implemented in app_secure.py. It applies simple improvements:

The password is loaded from the ADMIN_PASSWORD environment variable.
shell=True is removed.
The subprocess call uses a list of arguments instead of a shell command string.
MD5 is replaced with SHA-256.
Flask debug mode is disabled.

This secure version keeps the application easy to understand while showing how vulnerable patterns can be improved.

GitHub Actions Automation

The repository includes a GitHub Actions workflow at .github/workflows/bandit.yml. It runs on pushes and pull requests targeting the main branch.

The workflow checks out the repository, configures Python 3.11, installs dependencies, and runs:

python -m bandit -r . -f txt

This demonstrates how SAST can become part of a continuous integration process. Every push or pull request can be scanned automatically before changes are accepted.