Skip to content
All work
Software Development · Secure Coding
2025–26

Secure Coding Fundamentals

Two small Python builds that show security thinking, not just working code

PythonSecure CodingTesting Code
0
Uses of eval()
no code-execution path
29
Unit tests passing
incl. security suites
HMAC
Tamper-evident scores
SHA-256 signed log
2
Focused builds
calculator · card game

Context

Good security engineers can build the code they defend. These two Secure Coding (CSEC1003D) projects apply that mindset to everyday programs: assume input is hostile, and protect integrity even where nobody thinks to.

The problem

The naive version of each is a security hole. A quick calculator reaches for eval() — a remote-code-execution hole. A game writes a plain-text score file anyone can edit. The exercise was to build the correct version of each, and prove it with tests.

My approach

The calculator is a hand-written tokeniser + shunting-yard parser + fixed-operation evaluator, structurally incapable of running arbitrary code. The card game (War) uses clean OOP (Card / Deck / Player / engine) and signs every recorded result with HMAC-SHA256, so any edit to the score log is detected.

Safe expression calculator

The common “quick calculator” — eval(user_input) — is a remote-code-execution hole. This one classifies every character explicitly and only ever performs a closed set of maths operations, so hostile input is rejected before any computation.

  • Three stages: tokeniser → shunting-yard parser → RPN evaluator (no eval anywhere)
  • Rejects code injection and illegal characters at the lexer
  • Guards division-by-zero, domain errors and exponent-based DoS

Object-oriented War, with integrity

A clean OOP implementation (immutable cards, seedable deck, players, rules engine) — plus a security twist: every game result is appended to an HMAC-SHA256-signed log, and verification uses a constant-time comparison, so tampering with the score file is detected.

Tested and honest

29 unit tests across the two projects, including dedicated security suites (code-injection rejection, input-length and exponent guards, tamper detection, wrong-key verification). Both are on GitHub as secure-calculator and card-war.

Outcome

Two small but genuinely secure, tested projects — the developer literacy that strengthens day-to-day security engineering, built and verified rather than claimed.