Really appreciate your effort in discovering the seemingly zero-day vulnerability in Padu and reporting the same to the relevant team. Your effort has prevented a potential major data leak in the Padu system. Thank you!
I have a couple of comments for the points in the "What Would I Have Done Differently" section as I don't quite agree with some of them. Let me know if my comments make sense:
As long as there is a client (web app or mobile apa), we can't prevent API endpoints to be exposed caused a user can always inspect the source, the binary or monitor the network to know the endpoints, regardless public or private. I agree with rate limiting and cors restriction, but for public endpoints, we can't really protect with API key caused that is for private endpoints.
I would argue that it is ok to send the username and password "as is" to the server caused in Padu's case, those information will always be sent through a HTTPS secured channel. So it is not possible to sniff the network packet to view the data. I'm not too sure what you mean by "encrypted hashed". Encryption doesn't really work with a client caused it needs a key and the key stored at the client end will always be exposed. Hashing can be done at the server end before comparing with the hashed password in DB during authentication. So there is no need to hash it at client end.
For public endpoint, I think it is ok to use "NRIC Number" because that is the only identifier the user has to uniquely identify himself/herself. We do not have UUID for public endpoint caused the user has not logged in yet. For private endpoint, there is no need to send any identifier caused the JWT token should have enough information to identify the user.
This is a design choice. It is better if the Padu app can return the respective HTTP response codes matching the actual server processing status but the current Padu's design is just a different solution design that works for them.