It gives a clear rating, and readable, concrete advice to get you to the next level.

I also block the SSH port on the firewall level, unless I need to do some maintenance (and then I only unblock my IP address). So the SSL port is the only open port most of the time.

Hardware

I'm moving to late model hardware. My workstation is a 09/2018 computer. When Intel/AMD get Spectre/Meltdown solved in hardware, I'll probably buy an even newer computer. I'll try to buy as many non-Chinese components as I can. You can get a computer assembled in the U.S. But you still get parts made in China. As soon as possible I'll buy or accept a router from Verizon that uses WPA3. I'll turn off UPnP (Universal Plug and Play) if I can. Monitor the line (passive/active taps) Put the router behind a cage/door with a security lock. Move to a more secure office environment.

Software CSS (Content Security Policy - my code was probably written before or as the levels were being thrashed out) check what's going into and coming out of Local Storage ...

Tools Kali Linux Metasploit Wireshark AIDE SELinux Security Now with Steve Gibson & Leo Laporte ... Microsoft's Enterprise Security subscription, whitelist the computer programs that can run on Windows using their signatures

HTTP Security Headers. These are big. There are 8 or 9 of them now. Content Security Policy especially.

GeoIP Blocking. Also this is big. I think AWS WAF lets you even filter down to the state level now if you want. This dramatically reduces the open ip space you’re exposed to. Easy to circumvent yes, but still large benefits.

4096 SSL keys. Also would disable anything below TLS 1.1 (TLS 1.2 would be better).

SPF, DKIM, and DMARC records for DNS address.

IP Blacklists. Lots of known malicious IP lists you can download daily and block with IPTables. If you’re using Docker, you can block via Apache mod_rewrite and a fast look up dbm file (convert from txt to dbm via httptxttodbm tool).

ModSecurity. A pain to setup sometimes, but it’s not bad. Just enable a few options and you’re ready to go.

Why do you say this? You should keep in mind the following:

1. Most TLS vulnerabilities occur due to design or implementation flaws, not due to insufficient key size (in particular side channel attacks of various flavors);

2. RSA is not the only algorithm which can be used for TLS. In fact, it’s not even the most advisable one. You can also use authenticated encryption via AES-GCM or Curve25519. These are safer. “4096 bit keys” are not a coherent recommendation for these algorithms, because security doesn’t correlate with key size;

3. You generally want to choose libraries which are secure by default and don’t require (or encourage!) developers to make decisions about details like key sizes. Choose an algorithm if you kust (avoid RSA!), but limit further decision making.

A simple SQL injection in the code would still be exploitable regardless of the countermeasures above.

So on top of what you have suggested, what are your ideas to get the security right on the code level of the applications?

Somebody made good effort identifying some: https://www.hacksplaining.com/

Learn to think like somebody who will try to exploit your system and embed guards into your code as you build it.

Regarding reverse engineering, I personally feel that this is not as important an issue as others. Anyone that get's access to an app or a mobile device will always be able to reverse engineer it. It is just a question of time and effort. Mobile apps mostly should have the same objective as modern browsers, as providing the UI and UX.

Business logic and security should be handled on the backend side.

If you are still keen on reverse engineering and resiliency against it, check out this document https://www.owasp.org/images/6/61/MASVS_v0.9.4.pdf.

While leveraginvg serverless gives a lot of benefits in terms of hardening and infrastructure setup, all the traditional application security issues (e.g. OWASP TOP 10) like SQL injection can still apply.