DEV Community: Pranav Ghorpade

I Built a Secure REST API — Then I Tried to Break It

Pranav Ghorpade — Tue, 18 Aug 2026 18:03:32 +0000

A practical journey through API security, authorization, JWT, rate limiting, and common vulnerabilities.

Why this is a strong Medium story

Instead of writing a boring article titled "What is API Security?", make it a story:

I thought my REST API was secure because it had JWT authentication. Then I started testing what would happen if a user changed an ID in the URL.

That immediately creates curiosity.

OWASP's API Security Top 10 specifically highlights risks such as Broken Object Level Authorization, Broken Authentication, Broken Function Level Authorization, unrestricted resource consumption, SSRF, security misconfiguration, and improper inventory management.

Story structure

Authentication isn't authorization

Imagine:

GET /api/incidents/1001
Authorization: Bearer

The token is valid.

But what if user A can request:

GET /api/incidents/1002

and incident 1002 belongs to user B?

The API authenticated the user.

But it didn't authorize access to the object.

That's the difference between:

Authentication
"Who are you?"

Authorization
"What are you allowed to access?"

JWT doesn't automatically make an API secure

A typical flow:

Login
↓
Username + Password
↓
Spring Security
↓
JWT generated
↓
Client stores token
↓
API request
↓
JWT validation
↓
Authorization

But JWT validation alone doesn't solve:

privilege escalation
broken access control
insecure endpoints
excessive data exposure
rate abuse

Secure the endpoint

For example:

@PreAuthorize("hasRole('ADMIN')")
@GetMapping("/admin/incidents")
public List getAllIncidents() {
return incidentService.findAll();
}

But method-level security is only one layer.

Your service should also verify ownership where appropriate.

Never trust IDs from the client

This is dangerous:

incidentRepository.findById(id);

without checking whether the current user has permission to access it.

A better conceptual approach:

Request
↓
Authenticate
↓
Extract user
↓
Load resource
↓
Check ownership / permission
↓
Return resource

Rate limiting

An endpoint such as:

POST /api/login

can become a target for brute-force attempts.

A production API should consider:

Request
↓
Rate Limiter
↓
Authentication
↓
Authorization
↓
Business Logic

Security checklist

Before calling an API production-ready, check:

Authentication
Authorization
Input validation
Rate limiting
Secure headers
Error handling
Logging
Secret management
Dependency scanning
HTTPS
API documentation
Access control

OWASP maintains the API Security project specifically to help developers and security teams identify and mitigate these API-specific risks.

Ending

The biggest lesson wasn't how to implement JWT.

It was understanding that security isn't a feature you add to an API. Security is a property of the entire API design.

Tags:

Cybersecurity #SpringBoot #APISecurity #Java #Backend #OWASP

From First PR to Better Code: Mentoring a First-Time Open Source Contributor

Pranav Ghorpade — Thu, 13 Aug 2026 04:29:49 +0000

Today I had a small but meaningful experience as a mentor in IEEE Summer of Code.

I’m currently mentoring contributors working on an open-source Threat Incident Management System, and today I reviewed a first contribution from a first-time contributor.

This reminded me that open source isn't only about writing code. It's also about learning how to collaborate, review code, accept feedback, and improve an implementation.

🚀 The First Contribution

A contributor opened their first pull request to improve the frontend experience of our project.

PR #56 — Add a 1-click copy button for Incident IDs

The goal was simple:

SOC analysts frequently need to copy Incident IDs or IOC identifiers and use them in external tools. Instead of manually selecting and copying the ID, the contributor added a one-click copy button.

Changes included

Added a copy button to the Incident Detail page
Added a copy button to Incident cards
Added visual Copied! feedback
Used e.stopPropagation() to prevent unwanted navigation when clicking the button

It was a useful improvement and a great first contribution.

🔍 Reviewing the First PR

The initial implementation worked, but during the review I noticed a few areas where we could make the code more maintainable and robust.

I requested three improvements.

1. Add a Clipboard Fallback

The implementation relied on:

navigator.clipboard

I asked the contributor to add a fallback for environments where the Clipboard API may not be available, particularly in non-HTTPS contexts.

This is a good reminder that:

Code that works in one environment isn't necessarily code that works everywhere.

2. Create a Reusable Component

The copy-button behavior was being implemented in multiple places.

Instead of duplicating the same logic, I suggested moving it into a reusable:

CopyButton.jsx

This makes the component easier to maintain and allows the same behavior to be reused across the application.

The principle is simple:

Don't duplicate behavior when it can be encapsulated into a reusable component.

3. Improve Accessibility

I also asked for an aria-label on the button.

For example:

aria-label="Copy incident ID"

This helps make the interface more accessible and communicates the purpose of an icon-only button to assistive technologies.

🧑‍💻 What I Learned as a Mentor

This PR reminded me that code review isn't just about saying:

"This works. Merge it."

A good review should help contributors understand why a change is recommended.

In this case, the discussion was about:

Browser compatibility
Component reusability
Maintainability
Accessibility
User experience

And that's one of the things I enjoy about open source.

You get to work with people at different stages of their engineering journey, and a PR becomes more than just a code contribution — it becomes a learning opportunity.

🌱 First Contributions Matter

Seeing a first-time contributor open a PR is genuinely exciting.

Everyone starts somewhere.

That first issue, first commit, first pull request, first code review, and first merge can be an important step in someone's open-source journey.

As a mentor, I don't want contributors to simply submit code that passes a check.

I want them to gradually understand how professional software development works:

Issue
  ↓
Implementation
  ↓
Pull Request
  ↓
Code Review
  ↓
Feedback
  ↓
Improvement
  ↓
Merge

That's the real learning experience.

⚙️ Engineering Workflow

The PR also went through automated checks, including a SonarQube quality gate, and a Vercel preview deployment was generated for testing.

This is another important part of modern software development:

Write
  ↓
Test
  ↓
Review
  ↓
Analyze
  ↓
Deploy
  ↓
Improve

Even a relatively small frontend feature can go through a complete engineering workflow.

🎯 Final Thought

One of the best parts of contributing to open source is that you don't have to learn everything alone.

Someone can contribute code.

Someone else can review it.

The contributor learns from the review.

The project becomes better.

And the community grows.

That's what I hope to encourage through my mentoring experience in IEEE Summer of Code.

This was just one PR, but for a first-time contributor, it can be the beginning of a much bigger open-source journey.

First PR today. Better engineer tomorrow. 🚀

Project

Threat Incident Management System

An open-source security platform designed to help manage and investigate security incidents.

Contribution

PR #56 — 1-Click Copy Button for Incident IDs

Contributor: kunalRay21

Contribution: First open-source contribution

Program: IEEE Summer of Code

Role: Project Mentor

opensource #react #github #softwareengineering