Django penetration testing: Security assessment for Python web applications in Nigeria

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs Comprehensive Security Partner (CSP)

Django is often called the framework for perfectionists with deadlines. That is a dangerous combination. Deadlines force developers to take shortcuts. In Django, shortcuts usually mean disabling built-in security protections. When you disable a protection in Django, the framework does not stop you. It assumes you know what you are doing.

We specialize in Django penetration testing. We know exactly which shortcuts developers take when they build financial systems in Python. We know exactly how to exploit those shortcuts. We do not run generic vulnerability scanners against your server. We perform manual, aggressive security assessments targeting the unique architecture of your Django stack.

If your Nigerian fintech relies on Django REST Framework to move money, you cannot rely on automated tools. You need adversarial engineers who understand Python, ORM injection, and REST Framework permission logic.

Why Django apps still get exploited

Django provides CSRF protection, ORM query parameterization, password hashing, and clickjacking headers out of the box. Many engineering teams mistakenly believe this makes their application immune to attack. The framework's defaults are excellent. The problem lies in human implementation.

When developers disable these protections to meet a deadline, the framework cannot save them. They use @csrf_exempt decorators on API endpoints because the frontend team complains about token errors. They use raw SQL for complex reporting queries because the ORM is too slow. They leave DEBUG=True in production because they cannot reproduce a bug locally.

When they build Django REST Framework APIs, they write incomplete permission classes. They secure the list view but leave the detail view completely open. Our job is to find exactly where your team deviated from the secure path. We exploit those deviations to prove the financial impact.

1. Django ORM and raw query injection

Django's ORM parameterizes all standard queryset operations. It is very difficult to execute a classic SQL injection attack through a standard Model.objects.filter() call. However, fintech applications require complex data analysis. Developers frequently bypass the ORM to execute raw database queries.

The injection risk lies heavily in RawSQL(), extra(), and string formatting inside complex query conditions. We hunt for these exact patterns. We grep through your codebase for every single direct database interaction. We manually test any raw query path with advanced SQL injection payloads.

# VULNERABLE raw query using string formatting
def get_user_transactions(request):
    user_id = request.GET.get('user_id')
    # Injection: user_id is inserted directly into the query string
    transactions = Transaction.objects.raw(
        f"SELECT * FROM transactions WHERE user_id = {user_id}"
    )
    return list(transactions)

If your application uses PostgreSQL, we inject payloads that extract complete database schemas. If your application handles payments, we look for ways to manipulate the UPDATE statements to alter transaction amounts or wallet balances.

Beyond injection, we look for mass assignment vulnerabilities in Django REST Framework serializers. If your serializer declares fields = '__all__' and your view calls serializer.save() without overriding perform_create or perform_update, you have a massive vulnerability. Client-submitted JSON can write to any column on the model. This includes internal administrative flags like is_staff, is_superuser, or kyc_tier.

2. Django REST Framework permission class auditing

The most common critical finding on Django REST Framework APIs is an incomplete permission implementation. It causes Broken Object Level Authorization (BOLA). It destroys companies overnight.

Django REST Framework separates list-level permissions from object-level permissions. List-level permissions are handled by has_permission(). Object-level permissions are handled by has_object_permission(). Many developers implement the list-level check and assume object-level authorization is automatically handled. They are wrong. has_object_permission() is only called if the developer explicitly calls self.get_object() in the view. Direct ORM queries bypass the permission check entirely.

# VULNERABLE view: bypasses has_object_permission
class WalletDetailView(APIView):
    permission_classes = [IsAuthenticated]

    def get(self, request, wallet_id):
        # Fetches any wallet by ID, no ownership check performed
        wallet = Wallet.objects.get(id=wallet_id)
        return Response(WalletSerializer(wallet).data)

In the code block above, the system checks if the user is logged in. It does not check if the user actually owns the wallet they requested. We hunt for these flaws in every single endpoint. We map the entire authorization structure of your Django app. If one user can read another user's financial data, we will find it and report it immediately.

3. Django admin panel exposure and brute force

The Django admin panel is typically available at the /admin/ route. It is a powerful tool. It is also a massive liability. The admin interface is a full database management system directly connected to the internet. Even with strong passwords, a single compromised admin account gives read and write access to every model in the database.

We test three specific attack vectors against the admin panel. First, we attempt enumeration of admin usernames via timing differences in the login response. Second, we execute credential brute-force attacks. The Django admin does not throttle login attempts by default. If you have not installed a third-party library like django-axes, an attacker can guess passwords indefinitely.

Third, we look for admin panel access from compromised staff credentials. We search your public GitHub repositories, past data breaches, and accidental logs for active staff session IDs. We highly recommend restricting the admin panel to a strict VPN or internal IP range. You must also change the default URL prefix to prevent automated discovery.

4. DEBUG mode and information disclosure

Django's DEBUG mode is designed for local development. It produces incredibly detailed error pages. These pages include the full Python stack trace, the local variable values at each exact stack frame, the complete list of registered URL patterns, and all installed Django settings keys.

We have found DEBUG=True active in production environments in roughly one in five Django applications we audit in Nigeria. This usually happens after a frantic midnight deployment to fix a critical bug. The engineer turns on debug mode to see the stack trace and forgets to turn it off.

An attacker who triggers an unhandled exception receives a complete map of the application internals for free. They see your AWS keys, your database passwords, and your secret keys directly in the browser. We deliberately send malformed data to your endpoints to trigger these crashes. We verify that your production error handlers suppress the stack traces entirely.

5. Session and CSRF configuration

We audit your session cookie flags. Every session cookie must carry the HttpOnly, Secure, and SameSite attributes. We review your session expiry configurations. If your sessions last for thirty days without requiring re-authentication, your risk of account takeover increases exponentially.

We rigorously check the placement of @csrf_exempt decorators on views that modify data. Developers frequently disable CSRF protection on webhook endpoints or API routes that struggle with token validation. We exploit these exempted routes using cross-site request forgery attacks.

We also test whether your ALLOWED_HOSTS setting is correctly locked down. A permissive wildcard configuration allows HTTP Host header injection. This allows an attacker to poison password reset links, redirecting your users to a malicious phishing site when they request a password reset email.

What you get from a Simpa Labs pentest

We do not generate automated scanner PDFs. We write highly technical, actionable reports for your Python engineering team. We rank every finding by CVSS score and actual financial impact. We provide exact reproduction steps using standard terminal commands. Your engineers will not have to guess how we broke the app.

Most importantly, we provide the exact Django code snippet required to fix the flaw forever. We show you how to write the correct permission class. We show you how to parameterize the raw SQL query. We retest the application after you deploy the fixes, ensuring your platform is completely secure.

Related reading

Blog: Securing Django REST APIs · Flask penetration testing · API data leaks

Services: Penetration testing · API security testing