API Security and Application Security!

MIT App Inventor Help
, ,
#1

Hello everyone! We are waiting for help from everyone regarding security issues in the mobile applications you made in Mit App Inventor 2 today!

1-MOBILE APP SECURITY
2-API SECURITY

If there are people or extension who can help with these issues, please share!

The AES and hack protect extension in this example are an example of a protected mobile application! if the hack is successfully passed through the protect extension, the API is being solved inside, how do you think such a method is experimented with AES data replacement?

BLOCKS:

security
security1108×499 93.3 KB

#2

What issues would that be?

#3

No problem, I was just wondering your thoughts, what is the percentage of API key security in such an example?

#4

What can be done for more security?

#5

How should that be calculated? Everything is hackable, especially when you are putting the code inside your app, even when using the obfuscated text block.

You could put the code in a database somewhere and get it from there so it wouldn't be in your app.

Is there a special reason why you are asking this? Is this related to a project you are making that needs high security?

1 Like
#6

There is a financial project that I am really working on and I am dealing with vulnerabilities and trying to ensure the security of my API key and the application to protect the data of my users.

#7

Please help!

#8

I'm using Airtable and I have a lot of API keys the first priority is I pull the other API key from the server that can access the other user base from one base and process it like that, but I'm still worried!

#9

How did you find these vulnerabilities? Did you extract the apk you build?

#10

Still, hackers would be able to obtain the URL of your database and still might access the data.

1 Like
#11

image
image900×900 55.3 KB

1 Like
#12

For these types of "critical" projects, I recommend building an API on your own, and require users to have an account before connecting anywhere. When your users register with your app, you can give them a unique ID in your API side, and require all connections to be bound to that ID, so if someone is using your API for "bad faith", you will know who is doing that, and you will be able to take the related action.

You are putting the encrypted data in the app, and decrypting in the app again. It just feels like leaving a house key under the mat.

It of course slows someone who wants to inspect the app, when compared to storing credentials in a single text block, however, unless credentials are stored outside your app, the chances to get your credentials exposed will stay the same.

#13

it's just an API key inside other important data APIs are pulled from the server and decrypted and used!

A problem comes from the server with the network capture, the API is solved and the request is sent, can it be hacked?