Security Fuzzing
🌟 Objective
To discover vulnerabilities and robustness flaws through the automated, large-scale generation of malformed, unexpected or random inputs, with the aim of:
- Testing the limits of the application;
- Detecting unhandled exceptions, parsing failures, crashes;
- Reproducing anomalous behaviour or edge cases;
- Validating the application's resilience to inputs outside what is expected.
Fuzzing is essential for testing “the unexpected” - what planned tests do not cover.
🔍 What fuzzing is
Fuzzing is a security technique that consists of feeding the application with randomly or systematically generated inputs, with the intent of provoking errors, failures or crashes.
Common types:
- REST API fuzzing (inputs in JSON, headers, parameters);
- Fuzzing of binary protocols or structured messages;
- File or parser fuzzing (e.g. XML, PDF, image);
- Coverage-guided fuzzing (instrumentation to maximise the paths explored);
- Mutation-based fuzzing (variations on known real inputs).
⚠️ Fuzzing does not directly identify vulnerabilities - rather, error conditions that may indicate exploitable weaknesses.
⚙️ How to apply
- Select the target and test context (e.g. REST endpoint, file, API flow);
- Configure the fuzzer with the relevant input types (structure, types, encoding);
- Run fuzzing in an isolated or controlled environment, with observability (logging, crash dump);
- Instrument the application with coverage or exception detection (optional);
- Analyse anomalous or inconsistent behaviour: unexpected responses, silent failures, crashes;
- Report occurrences as robustness findings, with evidence and reproducibility.
✅ Good practices
- Use fuzzing on critical endpoints and external APIs;
- Prioritise rich formats (JSON, XML, JWT) and less validated fields;
- Repeat fuzzing after changes to parsing or input libraries;
- Use tools with coverage feedback for better exploration;
- Integrate fuzzing as a separate stage in the pipeline or in the nightly build;
- Combine with logs, tracing and crash reports for effective analysis.
📎 Cross-references
| Document | Strategic relevance |
|---|---|
| Chapter 02 - Requirements | Related to EX-REQ-309, EX-REQ-406 |
02-dast.md | Complements with more unpredictable inputs |
06-cobertura-e-priorizacao.md | Used in areas with fewer manual tests |
| Chapter 07 - Secure CI/CD | Applied in dedicated jobs or parallel environments |
08-gestao-findings.md | Fuzzing findings may require specialised triage |
Illustrative identifiers (EX-…); they do not correspond to the Ch. 02 Requirements Catalogue.
🎲 Fuzzing does not replace planned tests - but it increases invisible coverage, detecting flaws that only emerge with out-of-the-ordinary inputs. It is a sign of maturity in the security validation strategy.