Reviewing a Web Project for Basic Security Issues

Building a web project is useful.

Reviewing it for security issues is more useful for a cybersecurity portfolio.

A web app does not need to be large to have risk. Even a small site can have weak settings, poor input handling, missing headers, exposed files, or old packages.

This post shows a simple process for reviewing a web project through a security lens.

This is not a full penetration test.

It is a basic review to find common issues and improve the project.

Review Scope

The review focused on:

• HTTPS
• Security headers
• Input handling
• Error messages
• Exposed files
• Dependencies
• Basic abuse controls

The goal was to find clear issues and write simple fixes.

1. Check HTTPS

The first check is HTTPS.

Things to confirm:

• The site uses HTTPS
• HTTP redirects to HTTPS
• The certificate is valid
• There are no mixed content warnings
• Cookies use secure settings where needed

HTTPS is a basic control for public websites.

Without it, traffic can be exposed or changed in transit.

2. Check Security Headers

Security headers help the browser protect users.

Useful headers include:

• Content-Security-Policy
• X-Frame-Options
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy
• Strict-Transport-Security

Missing headers are not always critical.

But they can make some attacks easier.

Adding the right headers is a simple way to improve the site.

3. Check Input Handling

Any input from a user needs care.

This can include:

• Search fields
• Contact forms
• Login forms
• URL parameters
• API requests
• File uploads

The review should ask:

• Is input checked?
• Is output encoded?
• Are strange characters handled safely?
• Can a user send unexpected data?
• Does the app trust user input too much?

Poor input handling can lead to bugs like cross-site scripting or injection.

4. Check Error Messages

Error messages should help users without leaking system details.

Bad error messages can expose:

• File paths
• Stack traces
• Database errors
• Framework names
• Version numbers
• Debug output

A public site should not show internal errors to users.

The fix is simple: log the real error on the server and show a safe message to the user.

5. Check Exposed Files

Web projects can expose files by mistake.

Examples include:

• Old backups
• Test pages
• Debug routes
• Source maps
• Config files
• Admin pages
• Directory listings

These may not be serious on their own.

But they can give an attacker useful information.

6. Check Dependencies

Most web apps use packages.

Those packages need review.

Questions to ask:

• Are packages up to date?
• Are unused packages removed?
• Are known vulnerable versions present?
• Is there a lockfile?
• Is the project still maintained?

Dependency risk is part of web security.

A small project can still depend on unsafe code.

7. Check Abuse Controls

Some attacks are not complex.

A public form can be spammed.
A search page can be scraped.
A login page can be brute-forced.
An API can be hit too often.

Useful controls include:

• Rate limits
• Form validation
• Bot protection
• Logging
• Clear error handling
• Account lockout where needed

The goal is to make abuse harder.

Example Findings Table

What I Learned

This review helped me look at a web project in a different way.

Instead of only asking, “Does it work?”, I asked:

• What can a user control?
• What can leak?
• What could be abused?
• What should be restricted?
• What should be logged?

That is the main shift from development to security review.

Conclusion

A web security review does not need to start with advanced tools.

The basics matter.

Use HTTPS. Add security headers. Handle input safely. Hide internal errors. Remove exposed files. Keep packages updated. Add controls that reduce abuse.

For a cybersecurity portfolio, this kind of review is stronger than only showing that I built a website.

It shows how I think about risk.