Application-security portfolio demonstrating vulnerability analysis, insecure coding patterns, secure remediation, and re-testing across five common software-security weaknesses.
This repository contains paired vulnerable and secure implementations for:
- Buffer Overflow
- SQL Injection
- Cross-Site Scripting (XSS)
- Hardcoded Credentials
- Insecure Deserialization
The project is based on secure-coding coursework in which each vulnerability was:
Identified
↓
Analyzed
↓
Tested
↓
Remediated
↓
Re-Tested
The intentionally vulnerable examples are included for secure-development education and authorized laboratory testing only.
Application security is not only about finding vulnerabilities.
A complete secure-development workflow also requires understanding:
- Why the vulnerability exists
- Which trust boundary failed
- How the weakness can affect confidentiality, integrity, or availability
- Which coding practice addresses the actual root cause
- Whether the remediation still preserves legitimate functionality
- Whether the original attack condition can still be reproduced
The central methodology used throughout this repository is:
Vulnerable Code
│
▼
Security Analysis
│
▼
Controlled Validation
│
▼
Secure Implementation
│
▼
Re-Testing
│
▼
Remediation Confirmed
| Case | Vulnerability | Language | Vulnerable Pattern | Primary Remediation |
|---|---|---|---|---|
| 01 | Buffer Overflow | C | Unbounded gets() input |
Bounded fgets() |
| 02 | SQL Injection | Java | SQL string concatenation | PreparedStatement |
| 03 | Cross-Site Scripting | PHP | Raw user input rendered into HTML | htmlspecialchars() |
| 04 | Hardcoded Credentials | Python | Secrets embedded in source | Runtime environment configuration |
| 05 | Insecure Deserialization | Java | Unrestricted readObject() |
ObjectInputFilter |
The vulnerable C implementation allocates a fixed-size buffer:
char buffer[10];and then reads user-controlled input using:
gets(buffer);gets() performs no destination-boundary checking.
Conceptually:
Oversized Input
│
▼
Fixed-Size Buffer
│
▼
Boundary Exceeded
│
▼
Memory Corruption
Potential consequences include:
- Application crashes
- Corrupted application state
- Unpredictable behavior
- Control-flow manipulation in more advanced scenarios
The unsafe function is replaced with:
fgets(buffer, sizeof(buffer), stdin);which enforces a maximum write length.
Input
│
▼
Bounded Read
│
▼
Buffer Capacity Enforced
The original coursework reports that oversized input was re-tested after remediation and no crashes or memory corruption were observed.
The vulnerable Java example constructs a query by directly combining SQL syntax with user-controlled values.
String query =
"SELECT * FROM users WHERE username='"
+ username
+ "' AND password='"
+ password
+ "'";Conceptually:
SQL Syntax
+
User Data
│
▼
Executable Query
An attacker may therefore be able to influence the intended query logic.
Potential consequences include:
- Authentication bypass
- Unauthorized data access
- Database enumeration
- Data modification
- Destructive queries
The remediation uses:
PreparedStatementwith placeholders:
"SELECT 1 FROM users WHERE username = ? AND password = ?"and separately bound parameters:
statement.setString(1, username);
statement.setString(2, password);This separates:
SQL Structure
from:
User-Controlled Data
so supplied values are handled as data rather than executable SQL syntax.
The vulnerable PHP implementation directly reflects URL-controlled input into an HTML page:
<p>Welcome, <?php echo $_GET['name']; ?></p>The browser may therefore interpret attacker-controlled input as active page content.
Untrusted Input
│
▼
HTML Response
│
▼
Browser
│
▼
Potential Script Execution
Potential impact includes:
- Session theft
- Page manipulation
- Phishing
- User impersonation
- Malicious browser-side actions
The remediation applies context-appropriate output encoding:
htmlspecialchars(
$name,
ENT_QUOTES,
'UTF-8'
);The flow becomes:
Untrusted Input
│
▼
Output Encoding
│
▼
HTML-Safe Text
│
▼
Browser
The original coursework reports that the malicious test input was rendered as text after remediation and JavaScript execution no longer occurred.
The vulnerable example embeds authentication material directly in Python source:
USERNAME = "admin"
PASSWORD = "example-password"The problem is the storage location, not the particular demonstration values.
Conceptually:
Source Code
│
├── Application Logic
│
└── Authentication Secret
Anyone obtaining the source may also obtain the credential.
Hardcoded secrets may be exposed through:
- Source repositories
- Developer workstations
- Backup archives
- Reverse engineering
- Repository misconfiguration
- Accidental publication
They also make credential rotation more difficult.
The remediation externalizes configuration from source code:
USERNAME = os.getenv("APP_USERNAME")
PASSWORD = os.getenv("APP_PASSWORD")Conceptually:
Application Code
│
▼
Runtime Configuration
│
▼
Secret
The original coursework reports that after remediation no credential values remained in the source code.
The reusable examples in this repository use demonstration placeholders only. No real reusable secret is intentionally published.
The vulnerable Java implementation reconstructs arbitrary serialized objects:
ObjectInputStream ois =
new ObjectInputStream(inputStream);
Object obj = ois.readObject();without restricting which classes may be instantiated.
Conceptually:
Untrusted Serialized Data
│
▼
readObject()
│
▼
Object Reconstruction
│
▼
Potential Unsafe Behavior
Potential impact may include:
- Unexpected application behavior
- State manipulation
- Denial of service
- Gadget-chain execution
- Arbitrary code execution in vulnerable environments
The remediation introduces:
ObjectInputFilterto limit which object types may be reconstructed.
Example:
ObjectInputFilter filter =
ObjectInputFilter.Config.createFilter(
"com.myapp.*;java.base/*;!*"
);
objectInputStream.setObjectInputFilter(filter);Conceptually:
Serialized Data
│
▼
Object Filter
/ \
Allowed Rejected
│
▼
Deserialize
Where practical, data-only formats with explicit schemas are preferable to native object deserialization for externally controlled input.
The five case studies affect different technologies, but a common pattern appears repeatedly:
Untrusted Data
│
▼
Trusted Too Early
│
▼
Unsafe Operation
│
▼
Security Vulnerability
The remediation introduces an explicit security boundary.
| Vulnerability | Missing Boundary | Secure Boundary |
|---|---|---|
| Buffer Overflow | Memory capacity | Bounded input |
| SQL Injection | SQL syntax vs. user data | Parameterized query |
| XSS | HTML code vs. user data | Output encoding |
| Hardcoded Credentials | Source code vs. secret material | Externalized secret configuration |
| Insecure Deserialization | Arbitrary object vs. expected type | Object filtering / schema validation |
A major theme of the project is re-testing.
The workflow is not:
Find Vulnerability
↓
Change Code
↓
Done
Instead:
Find Vulnerability
│
▼
Establish Reproducible Test
│
▼
Implement Fix
│
▼
Repeat Original Test
│
▼
Confirm Security Condition Changed
The original coursework documents successful re-testing across the case studies.
The coursework maps the vulnerabilities to OWASP Top 10 (2021) categories.
| Vulnerability | Coursework Mapping |
|---|---|
| Buffer Overflow | A04 — Insecure Design |
| SQL Injection | A03 — Injection |
| Cross-Site Scripting | A03 — Injection |
| Hardcoded Credentials | A07 — Identification and Authentication Failures |
| Insecure Deserialization | A08 — Software and Data Integrity Failures |
These mappings preserve the classification used in the original assessment.
The case studies reinforce several secure-development principles.
Applications should define and enforce expected input constraints.
User-controlled input should never become executable SQL structure.
Untrusted content should be encoded for its browser output context.
Memory operations should enforce destination capacity.
Secrets belong in controlled configuration or dedicated secret-management systems, not application source.
Applications should not reconstruct arbitrary native objects from untrusted input.
Application and database accounts should receive only the permissions they require.
A remediation should be validated against the original vulnerable condition.
The project places individual code fixes within a broader secure-development lifecycle.
Requirements
│
▼
Secure Design
│
▼
Implementation
│
▼
Security Testing
│
▼
Deployment
│
▼
Monitoring & Maintenance
Security should be integrated throughout software development rather than treated as a final-stage activity.
The original coursework uses or discusses techniques including:
- Manual code review
- Manual fuzzing
- Compiler warnings
- Static analysis
- Dynamic testing
- HTTP request manipulation
- Browser testing
- OWASP ZAP
- Burp Suite
- Secret scanning
- Dependency analysis
- Re-testing after remediation
No single testing approach identifies every class of vulnerability.
A stronger application-security program combines multiple complementary techniques.
This repository intentionally separates two forms of material.
Located under:
evidence/screenshots/
These screenshots preserve selected evidence from the original assessment.
Located under:
vulnerable-code/
secure-code/
These implementations make each vulnerable/secure comparison easier to inspect directly through GitHub.
The clean examples preserve the same root security concepts while improving readability and organization.
secure-coding-application-security/
├── README.md
├── LICENSE
│
├── docs/
│ └── methodology.md
│
├── evidence/
│ ├── README.md
│ └── screenshots/
│ ├── 01-buffer-overflow-testing.png
│ ├── 02-buffer-overflow-remediation.png
│ ├── 03-sql-injection-testing.png
│ ├── 04-sql-injection-remediation.png
│ ├── 05-xss-testing-and-remediation01.png
│ ├── 05-xss-testing-and-remediation02.png
│ ├── 06-hardcoded-credentials-vulnerable.png
│ ├── 07-hardcoded-credentials-remediation.png
│ ├── 08-insecure-deserialization-vulnerable.png
│ └── 09-insecure-deserialization-remediation.png
│
├── vulnerable-code/
│ ├── buffer-overflow/
│ ├── sql-injection/
│ ├── xss/
│ ├── hardcoded-credentials/
│ └── insecure-deserialization/
│
└── secure-code/
├── buffer-overflow/
├── sql-injection/
├── xss/
├── hardcoded-credentials/
└── insecure-deserialization/
| Resource | Description |
|---|---|
| Secure Coding Methodology | Assessment and remediation methodology |
| Evidence Walkthrough | Original coursework evidence |
| Buffer Overflow | Memory-safety case study |
| SQL Injection | Database-query security |
| XSS | Browser output security |
| Hardcoded Credentials | Secret-management case study |
| Insecure Deserialization | Object deserialization security |
This project demonstrates practical understanding of:
- Secure Coding
- Application Security
- Vulnerability Analysis
- Security Remediation
- Security Re-Testing
- C Memory Safety
- Buffer Overflows
- Java
- SQL Injection
- Parameterized Queries
- PHP
- Cross-Site Scripting
- Output Encoding
- Python
- Secret Management
- Insecure Deserialization
- Object Filtering
- Static Analysis
- Dynamic Testing
- Burp Suite
- OWASP ZAP
- Secure SDLC
- OWASP Top 10
The code examples are intentionally small and designed to isolate specific vulnerability classes.
Production applications would typically require additional controls such as:
- Centralized authentication
- Strong password hashing
- Formal secret-management platforms
- Dependency scanning
- SAST
- DAST
- Software Composition Analysis
- CI/CD security gates
- Content Security Policy
- Centralized logging
- Secure error handling
- Runtime monitoring
- Security code-review processes
These are production recommendations rather than claims about the original coursework implementation.
This repository represents secure-coding and application-security laboratory work.
It should not be interpreted as evidence of:
- Production application deployment
- Production penetration testing
- Formal security certification
- Enterprise DevSecOps implementation
- Production WAF operation
- Real credential compromise
- Third-party application exploitation
The project focuses on understanding vulnerable patterns and demonstrating safer alternatives.
The intentionally vulnerable code is included solely for:
- Secure-development education
- Defensive application-security learning
- Authorized laboratory testing
- Technical portfolio demonstration
Do not use these examples to attack systems without explicit authorization.
Ravi Prajapati
Cybersecurity | Application Security | Enterprise IT | Security Operations