When it comes to security; techniques refer to the methods or approaches employed to safeguard information or systems. Revealing details about your security system, even indirectly, can pose a risk.
For example, stating "I open my door with an NFC key" discloses the presence of an *NFC reader*, potentially suggesting a point of vulnerability. Similarly, mentioning "entering your house through a window using a lever" reveals a technique for unauthorized access.
Therefore, it's crucial to avoid disclosing specific details about security measures to prevent potential risks. Instead, focusing on broader security principles and best practices can help maintain a higher level of confidentiality and protection for your systems.
Absolutely, being aware of common techniques used in hacking and cracking is crucial for enhancing security. Understanding potential vulnerabilities and attack vectors allows you to fortify your defenses. It's like staying one step ahead by anticipating the strategies that malicious actors might employ.
Silly example of POST method
- I must send data from a form (key value dictionary) in Json format to my backend.
The most common practice is to grab each header and value and send it raw in a POST method.
If someone intercepts the Json, they will be able to read the data sent (since many times it is not necessary to modify the information).
In that intercepted Json, silly information can go (such as; no information is silly) as well as your GPS coordinates and DNA records.
Which you can use to send a swarm of collaborative drones, full of nitroglycerin (homemade and gluten free) directly to crash into you.
- "Conventions" are always used to send information, such as;
user_name, password, email. So all the attacks are directed at those conventional labels (attackers are smarter than teachers).
So... what happens if you change those labels to meaningless phrases like; email to xcvdfand my_email@my_domain.com to as909f0a9dd8a9sd90a0sdfhas676s5a5 using an encryption algorithm (as you please).
look (an read) the Json now; xcvdf : as909f0a9dd8a9sd90a0sdfhas676s5a5 and tell me what you see.
¿the header: is it a username, password, domain, age, pseudonym?
the value: is it an email, domain, account, etc? is it encrypted? in what algorithm? What if it is not encrypted and is 100% true?
No system is infallible, but many times it is about gaining security through the time and interactions that the attacker(s) spend intercepting your communications and systems (to trace them).
- Both in that: on the server side, it is important that there are functions that
filter them every time a POST is received, such as: every time the xcvdf header is received, the value is saved in "GPS" and in "DNA". And Any other header to this table or collection should be rejected
- Regardless of the type of
application, it is always good to save the data encrypted and only decrypt it on the client side (not before being sent). only by those users who must see the information or have access to it (creator or administrator user).
Silly example of GET method
- Continuing with the previous example: every time a GET request is made, it is usually set;
user_name from table or collection.
and the GET is a dangerous method if they have already deciphered the schema of your DB (precisely, using very common names in the tables or collections)
- Instead of using a GET, you can choose to use a POST method, to bring information through a
function on the server side.
- Example: every time the POST is received with the header
jdsfjl with the argument: pipiricucu, bring me the last 10 records of the table or collection orders where the products exceed $1000.
- Example: every time the POST is received with the header
jdsfjl with the argument: pipiricucu; decrypt pipiricucu with (algorithm you use), and look for the decrypted value in the table or collection customers and orders, bringing the last 100 records from the email column where the decrypted value is equal to that of the row.
- Example: every time the POST is received with the header
jdsfjl with the argument: pipiricucu; creates a table or collection with the name TTD [Target To Destroy] where the value pipiricucu matches the value in the column DNA, bringing them all together medical records, purchases, family, pets, friends and close acquaintances. and send them in an encrypted Jsonb to the fleet of killer drones that are closest to the target.
Using server-side functions and avoiding GET methods, you avoid (to) SQL injection and decryption of the DB schema, and it is also good to disable or filter the GET method (with a function) so that not just anyone can use it.
Good security practices (general and basic) are extremely well known by attackers, because they are also super hyper mega ultra used by coders and companies that do not hire programmers (because they are very expensive 
). But there is nothing more expensive than a data security failure.
Thanks to the fact that today there are BaaS such as Firebase, Aws and Supabase (among many others), security in terms of hardware and engineering is no longer so expensive for mere mortals like us.
But even so, security on our part must be essential, following the principle of zero trust (Google and Amazon engineers will thank you)
Even using limited and basic platforms such as NoCode, the principle of zero trust must be used, with technique and knowledge, relying on the tools that are available.
Silly example of LOCAL STORE DATA method
- It is always required to
save data locally in some type of file (Json, JS, csv, TinyDb, etc) and 'always' with sensitive information (no data is silly).
Then, you can encrypt what you are going to save; my_data to kjfiwikfkskkaaw11e5w, encrypt the file from my_csv to usduiasalkkfqla.csv, then you can proceed to remove, add or change the extension, from; usduiasalkkfqla or usduiasalkkfqla.sxd
That way, within the code, you can do whatever needs to be done each time you need to save or read data.
It doesn't matter if the original file is csv and you change the extension to Jsonb (after encrypting it), because as I said, on the client side you are limited in a certain way, but you can still do a lot, such as; Make the attacker waste as much time as possible trying to decipher the undecipherable (the programmer), until he loses patience and abandons the target.
And that's what I mean by techniques and strategies.
Maybe @Taifun @Silver @vknow360 @Anke 
They can contribute more to the cause, since they know more about Java and how it is the core of app inventor, I am very new to the platform, I don't even know how to use RUSH for my Supabase extension (without making my PC commit suicide) 
Greetings from Argentina 
to the world.
- If found it useful, here is your like.
- I wish you weren't Argentine.
- ChatGPT will take your job.
