My Bug Bounty Report Was Marked N/A. Then I Received $1,200.

I was expecting feedback on a bug bounty report. Instead, the first response said the issue could not be reproduced and marked it Not Applicable.

The reviewer also said the report did not contain a clear enough proof of concept, lacked technical details, and appeared potentially AI-generated.

That was not the result I had hoped for.

Later, the program confirmed two security findings from the same submission. One received a P4 reward of $200. The other received a P3 reward of $1,000.

The total was $1,200.

This is how the investigation unfolded, what I actually proved, and what I would do differently next time.

The target has been anonymized. The examples use example.com, and some technical details have been generalized to avoid identifying the affected program. This is an account of my own investigation, not a claim of affiliation with the organization.

How the investigation started

I was looking beyond the endpoints that appeared in ordinary crawling and the application's client-side code. I wanted to understand what the backend exposed and whether its API behavior matched the access restrictions a user should have.

During that work, I found an API schema endpoint that returned internal API documentation without authentication.

An API schema describes the operations an application supports, including routes, parameters, request formats, and response structures. Developers use this information to understand and integrate with an API.

There is nothing inherently wrong with publishing API documentation. The question is whether the particular documentation is intended to be public.

In this case, the document appeared to describe internal functionality rather than a documented public API. It contained a much broader view of the backend, including administrative operations and internal services.

That gave me another direction to investigate.

Finding one: API documentation exposed without authentication

The schema was accessible through an HTTP request without logging in.

For an anonymized example, imagine an endpoint at:

https://api.example.com/api/v2/swagger_doc

A request to an endpoint like this should be evaluated in context. A publicly accessible schema can be intentional, so its existence alone does not establish a security vulnerability.

What mattered in my investigation was the nature of the information being exposed. The document described internal operations that were not apparent from ordinary crawling or the application's JavaScript bundles.

It provided a map of functionality that would otherwise have been much harder to discover.

That did not mean every route in the document was vulnerable. Each operation still needed to be examined on its own, especially where authentication and authorization were involved.

The program later confirmed the API schema disclosure and said it had issued a fix. This finding received a P4 rating and a $200 reward.

Finding two: An administrative operation accepted a low-privilege account

The second finding was more significant.

While examining the operations described by the schema, I tested an administrative endpoint using a normal worker account rather than an administrator account.

The endpoint was supposed to have a stricter access requirement. A low-privilege user should not be able to invoke an administrative action simply because they know its URL or can construct an HTTP request.

However, the request returned HTTP 200 with a response indicating success:

{"success":true}

I then compared this behavior with other administrative endpoints. Using the same low-privilege account, those endpoints correctly returned HTTP 403.

That comparison mattered.

A single successful HTTP response can be misleading. It might indicate that a request was accepted, not necessarily that the intended operation completed. But the difference between an endpoint returning success and related administrative endpoints rejecting the same account was a strong reason to investigate the authorization boundary.

The program subsequently validated the endpoint as lacking proper access controls and awarded a P3 reward of $1,000.

There is an important limitation to what I could demonstrate. The test environment had sparse data, and I could not independently verify a persistent change through a read-back operation. I did not claim that I had conclusively changed a real leave request, accessed personal records, or retrieved payroll data.

I reported the authorization weakness supported by the evidence I had.

That distinction matters in security research. A report should describe the impact that has actually been demonstrated, not the worst outcome someone can imagine.

The first response was N/A

The original response was clear: the reviewer could not reproduce the issue from the information provided.

The feedback also mentioned insufficient technical detail and concerns that the report might be low-quality or AI-generated.

I had submitted two findings together, but my report had not given the reviewer a sufficiently clear path to validate the claims at that stage.

It is easy to concentrate on discovering a vulnerability and treat the report as the final administrative step. In practice, the report is part of the technical work.

A reviewer needs to understand what account was used, what request was sent, what the application should have done, what it actually did, and how the evidence supports the claimed impact.

If those pieces are unclear, even a legitimate issue can take longer to assess.

The later decision was different. The program confirmed the schema disclosure, said it had fixed it, validated the missing access control on the administrative endpoint, and awarded both findings.

I cannot infer every reason behind the change from the two responses alone. What I can say is that the later response explicitly recognized both issues and assigned each its own priority and reward.

The final result

The rewards were divided as follows.

FindingPriorityRewardAPI schema disclosureP4$200Missing access control on an administrative API operationP3$1,000Total $1,200

The program also gave me advice for future submissions: report separate findings separately so that each can be validated on its own.

That is advice I will take seriously.

Two bugs can be discovered during the same investigation and still require different reports. They may have different root causes, different impacts, different fixes, and different severity ratings.

Keeping them separate makes it easier for a reviewer to understand exactly what is being reported.

What I learned from this report

1. Finding an endpoint is only the beginning

Discovering an undocumented route can be valuable, particularly when it exposes internal functionality. But the route itself is not the entire vulnerability.

I still need to establish what should be accessible, what is actually accessible, and why that difference matters.

2. Compare the expected behavior with the actual behavior

The administrative endpoint became more interesting when I compared it with related endpoints using the same account.

The comparison helped distinguish an ordinary request failure from a possible authorization weakness. It also gave the report a concrete control case rather than relying on an assumption about what the server should do.

3. Be honest about what the evidence cannot prove

A successful status code is not always proof of a completed action. A route that describes sensitive functionality does not automatically prove that sensitive data was accessed.

Being precise about these limitations makes a report more credible. It also prevents a researcher from making claims that the available evidence cannot support.

4. AI assistance does not replace manual verification

AI tools can help organize reconnaissance, inspect API descriptions, generate ideas for tests, and structure a report. They can also produce explanations that sound convincing without being correct.

The responsibility still belongs to the researcher to validate the requests, understand the results, and distinguish observations from assumptions.

The reviewer's concern about AI-generated content made the quality of the technical evidence particularly important in this case. The way to address that concern in future work is to ensure that each claim is tied to an experiment and a result I can personally explain.

5. Make the report easy to reproduce

The reviewer should not have to guess which account to use, which operation to test, or what result would demonstrate the issue.

A useful report makes the reproduction steps explicit, explains the expected and actual behavior, identifies the evidence supporting the impact, and states any limitations.

I also need to submit distinct findings separately when they represent separate vulnerabilities.

What I will change in future reports

I will separate unrelated findings instead of placing them together in one submission. I will make the reproduction steps more direct, include clear evidence for each major claim, and explain exactly what I verified.

I will also be more careful about the difference between a potentially vulnerable endpoint and a demonstrated security impact.

The $1,200 reward was a good result, especially this early in my bug bounty journey. But the most useful part of the experience was learning that finding a problem and presenting a convincing technical case for it are two different skills.

My first response was N/A. The later response confirmed two findings.

Next time, I want the first report to be clear enough that the reviewer can reproduce the issue without having to work out what I meant.