The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Project Title
Web Application Penetration Testing | SQL Injection & Security Assessment
Project Description (Copy & Paste to Contra)
This project demonstrates a simulated web application penetration testing assessment focused on identifying critical security vulnerabilities and understanding their potential impact on application security.
The demonstration follows a realistic attack scenario in an authorized lab environment, showing how a SQL injection vulnerability could lead to unauthorized administrative access, sensitive database exposure, and application compromise.
Key Areas Covered
Web Application Penetration Testing: Identifying and assessing application security vulnerabilities.
SQL Injection Testing: Demonstrating SQL injection risks in authentication functionality.
Authentication & Authorization: Evaluating potential unauthorized administrative access.
Database Security: Understanding sensitive data exposure risks.
Privilege Escalation: Demonstrating the potential impact of elevated access.
Persistence Risk Assessment: Highlighting security risks following an application compromise.
Security Reporting: Communicating vulnerabilities, risks, and potential business impact.
Technologies & Skills
Burp Suite
Web Application Security
OWASP Top 10
SQL Injection
Penetration Testing
Vulnerability Assessment
Ethical Hacking
Security Risk Analysis
My Role
Application Security Engineer | Penetration Tester | Cybersecurity Consultant
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
The most dangerous system failure may still be green.
A form submits successfully.
A webhook returns 200 OK.
The workflow finishes without an error.
But no useful record reaches the destination.
That is the next case I’m adding to a controlled intake-system demonstration for MLOpsLab.
Instead of trusting execution status alone, the test will compare:
what the process expected;
what it accepted;
what it processed;
what was actually committed;
why an item produced no output.
The intended distinction is:
Completed: the expected result exists.
Legitimately empty: zero output was correct.
Incomplete: work was accepted, but the expected result is missing.
This matters beyond workflow automation.
A customer enquiry can receive a confirmation without reaching the team.
An AI assistant can say details were saved when storage failed.
A report can load successfully while omitting one source.
The useful question is not simply:
“Did the system run?”
It is:
“Can we verify that the intended business outcome happened?”
This remains a controlled demonstration using synthetic data, not a production or client-result claim.
#MLOpsLab #SystemsEngineering #WorkflowReliability
Rate limiting isn’t “npm install + two lines in nginx.”
Most tutorials make it look trivial: add a throttler package to NestJS, add limit_req to nginx, done.
Problem 1: your server sees the proxy, not the user.
Behind nginx, every request arrives from the proxy’s IP. So the whole site shared ONE rate limit. Ten login attempts per minute for everyone. Anyone could lock all users out.
The fix is one line in main.ts (app.set('trust proxy', 1)) plus forwarding X-Forwarded-For in nginx. The number matters: true trusts any client-supplied header and lets attackers spoof their IP. 1 trusts exactly one hop.
Problem 2: CSR and SSR see different IPs.
Client-side calls (login, refresh) go browser --> nginx --> API, so the API sees the real user IP.
But with Next.js SSR on a serverless platform like Vercel, the page is rendered on Vercel’s servers. The API sees a pool of cloud IPs, not your visitors. Every SSR visitor shares the same few IPs, and therefore the same quota.
The fix: the SSR layer forwards the visitor’s IP in a custom header, signed with a shared secret. The API only trusts that header when the secret matches. Without the secret check, anyone could forge the header and bypass your limits.
Lesson: rate limiting is an architecture problem, not a package. Know where your IP is lost, and who you trust.
Building an offline exam-prep app for engineering students in Nigeria, where data and power are unreliable. Timed questions, instant scoring, zero internet needed. Built with HTML, CSS, and JavaScript. Open to freelance work in web apps, electronics, and technical content.
