My BSc dissertation wasn't a literature exercise, it was a controlled experiment. I built two parallel versions of a banking web app, one deliberately vulnerable and one hardened, then ran a real four-method comparison (manual penetration testing, SonarQube, OWASP ZAP, and Snyk) plus a 24-developer survey to answer one question: how are OWASP Top 10 threats best managed in modern web applications? First Class Computer Science graduate, open to PhD opportunities in software engineering, robotics, human-robot interaction, and intelligent systems.
90.44%
Degree Average
P81
Project & Professionalism (6CS007)
4
Detection Methods Compared
24
Developers Surveyed
About Me
I graduated from the University of Wolverhampton with a First Class BSc (Hons) in Computer Science, finishing with a 90.44% average across three years, including a perfect 100% in Introductory Programming, Fundamentals of Computing, and Object-Oriented Design, and a P81 on my final-year dissertation module. But the grades sit on top of something more useful: I'd already spent three-plus years shipping production software professionally before I wrote a single page of that dissertation, architecting backend microservices at Stax Payments, building omnichannel notification systems at AYU Digital, and reducing technical debt through TypeScript migrations at Humongous.io.
I've also spent years explaining technical ideas to other people, 15+ published technical articles with 443K+ combined readership on freeCodeCamp, plus hands-on teaching roles covering backend development, Laravel, and Python across multiple bootcamps and career expos. Research is only as useful as it is communicable, and that's a muscle I've been building for a while.
See the Engineering Path ↗Looking Ahead
I'm not narrowly fixed on security research. I'm genuinely curious about how intelligent systems behave, how humans and machines can collaborate better, and how software engineering as a discipline keeps up with both, and I'd rather work on a well-posed question in an area I'm still learning than a shallow one in an area I already know.
Below is the one formal research project I've done so far, my BSc dissertation, which convinced me I want more of exactly this: picking a genuine open question, building whatever's needed to test it properly, and following the evidence even when it complicates the story. If you're supervising or hiring for research that needs someone who can both write the paper and build the artefact, I'd love to talk.
Dissertation
Now, a closer look at research I've done before, the BSc dissertation behind those numbers above. It wasn't a literature exercise; it was a controlled experiment.
Academic Question
"How can OWASP Top 10 threats be best managed in modern database-driven web applications?"
Rather than surveying the literature and stopping there, I built the artefact needed
to actually test it: a full-stack banking-style web application, engineered in two
parallel versions under an A/B methodology. Version A deliberately
implements all ten OWASP categories, from SQL injection built via raw string
concatenation to a hardcoded JWT secret and a vulnerable node-serialize
dependency enabling remote code execution. Version B is the same
application rebuilt with parameterised queries, bcrypt password hashing, UUID
primary keys, strict server-side authorisation, structured logging, and SSRF-safe
URL validation.
Both versions were deployed independently and tested under identical conditions by four manual penetration testers and three industry-standard automated tools, SonarQube (SAST), OWASP ZAP (DAST), and Snyk (SCA), with every finding logged against its OWASP category, severity, and detection method. I paired this with a 24-respondent developer survey on real-world security awareness and remediation behaviour, giving the research both a technical and a human-factors dimension.
Findings
Each tool was run against both versions under identical conditions. The headline numbers below are the vulnerable-version baseline against the secure-version result.
44 → 0
21 vulnerabilities (13 BLOCKER SQL injection findings across all 5 backend controllers) plus 23 code smells on Version A. Zero findings on Version B, every taint flow the tool targets was eliminated.
15 → 11
Alert types dropped from 15 to 11; medium-severity CORS and CSP misconfiguration alerts were eliminated entirely between versions.
15 → 14
Correctly isolated the critical node-serialize
arbitrary-code-execution dependency and confirmed its removal in Version B.
8/10
Four independent testers covered 8 of 10 OWASP categories, the broadest single-method coverage, including business-logic and access-control flaws no automated tool detected.
Comparative Analysis
Mapping all ten OWASP categories against every detection method exposed a clear pattern: automated tools excel at code-level and dependency issues, while business logic and access control flaws remained almost exclusively the domain of human testers.
| OWASP Category | Manual | SonarQube | OWASP ZAP | Snyk |
|---|---|---|---|---|
| A01 – Broken Access Control | ✓ IDOR, external DB | ✗ | ✗ | ✗ |
| A02 – Cryptographic Failures | ✓ hardcoded JWT | ✓ BLOCKER | ✗ | ✗ |
| A03 – Injection | ✓ SQLi + XSS | ✓ BLOCKER × 13 | ~ inferred (5xx) | ✗ |
| A04 – Insecure Design | ✓ negative transfer | ✗ | ✗ | ✗ |
| A05 – Security Misconfiguration | ✓ env vars, errors | ✓ SSRF flag | ✓ CORS, CSP | ✗ |
| A06 – Vulnerable Components | ✗ | ✗ | ✗ | ✓ node-serialize RCE |
| A07 – Auth Failures | ~ partial | ✗ | ✗ | ✗ |
| A08 – Software Integrity | ✗ | ✗ | ✗ | ✗ |
| A09 – Logging & Monitoring | ✗ | ✗ | ✗ | ✗ |
| A10 – SSRF | ~ untested (bug) | ✓ MAJOR | ✗ | ✗ |
✓ confirmed finding · ~ partial / inferred · ✗ not detected — full methodology and per-category detail in the dissertation.
Artefact Design
Nothing in Version A was accidental. Each OWASP category was introduced through a targeted implementation choice, then mitigated with a specific, verifiable fix in Version B.
Injection. Raw string-concatenated SQL across
all five backend controllers → replaced with parameterised queries using numbered
placeholders, verified separately via bcrypt.compare().
Cryptographic Failures. Plaintext passwords
and a hardcoded JWT secret committed to the repo → bcrypt hashing (cost factor 12)
and a required JWT_SECRET environment variable, refusing to boot if
absent.
Broken Access Control. Sequential integer primary keys and trust in client-supplied IDs → UUID primary keys and server-side ownership checks returning 403 on mismatch.
Insecure Design. Transfer endpoint accepted negative amounts, enabling fraudulent self-credit → Joi schema validation plus an explicit positive-amount guard before any database write.
Vulnerable Components & Integrity.
node-serialize deserialising cookies on every request (arbitrary code
execution) → removed entirely, replaced with signed, httpOnly,
sameSite: strict JSON cookies.
Logging & Monitoring. No logging
infrastructure at all → structured Winston logging of every auth, transfer, and
access-control event to rotating files and a system_logs table.
SSRF. Avatar upload fetched any user-supplied
URL with no validation → an isSafeUrl() guard blocking non-HTTPS
schemes and private/loopback address ranges before any outbound request.
Human Factors
Technical results only tell half the story, so I ran a 24-respondent survey of developers across experience levels to see how security awareness translates — or doesn't — into practice.
63%
Had prior awareness of the OWASP Top 10 before the survey
67%
Rated their confidence detecting critical issues as only 3/5
75%
Would fix a critical-but-slow vulnerability before a quick, moderate one
2
Respondents with 5+ years' experience rated themselves "not familiar at all"
Let's Connect
I'm looking for PhD opportunities in software engineering, robotics, human-robot interaction, or intelligent systems, somewhere I can keep building real artefacts to test real questions, the way this dissertation started. If you're supervising or know a lab that is, I'd love to hear from you.