I am testing a mobile app that makes requests to a web service. Web service has two sets of functions. Class A functions can be called before login and Class B functions can be called after login. Class B functions are protected by user credentials and can only be called if the user is logged in and retrieved a token. Class A functions on the other hand can be called by anyone. Dev team used basic auth. to protect these services from ordinary internet users but they put the username and password in to the application. Credentials are hardcoded in to the application. I dont like to keep this data in the app because if for any reason we need to change the password we have to push an update to all users. If a user does not update their app, they cannot login because login request needs to be sent with basic auth credentials. I asked developers to remove the credentials from the app and they asked for a meeting. I have to defend my case and offer an alternative. Is there any other good reason to not keep these credentials in the app and what is the best practice to follow? Thanks.

1 Answer 1


Basic Auth obviously could protect from ordinary internet users but it definitely will not protect from hackers, because such credentials are easily obtained from the app or its traffic. So you could ask about the threat model. On the other hand your operations (dev) team got the additional unnecessary task (and potential point of failure) to support and update this shared secret.

Best practice here is to build a resilient architecture with strong actual authentication for Class B functions approved by industry.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .