6 ms·

Ask HN: How to secure website for public launch

94 points by smarri 3y ago

Id like to launch a website project online. It has some functionality e.g. user can input search parameters to find specific locations using Goole maps API, and search based on device location. I'm concerned about my program not being robust enough from a security point of view, e.g. where user input occurs, I'm not confident I can manage malicious actors. How do you launch websites that use a front and back end, securely? I'm confident in launching static websites, reasonably experienced in python, PHP, (but only for localhost personal project work), this is really me taking the big leap from localhost projects to live. Are there third party services that give extra security, or is it a case of learning this side of software from first principles? Thanks in advance.

joshxyz 3y ago
you can always rollback.
- tatersolid 3y ago
  And get compromised again immediately after said roll-back? Fast roll-back/restore is a useful feature for improving availability but does nothing to improve security.
mrkeen 3y ago
* keep your software & dependencies patched * Disable SSH access for 'root' username. * If you're using JWTs anywhere, don't mistake them for encryption - they are not. * Check you're only serving over https. * Don't trust your frontend. Any security check built into the frontend is near-useless, as the user can reprogram it however they like. * Strings is how you let the baddies in, especially if you manipulate and concatenate them. Read about SQL injection to find out more.
- anonymouse008 3y ago
  > * If you're using JWTs anywhere, don't mistake them for encryption - they are not. I would love to understand the assumptions that lead to this belief. It makes negative sense?
  - mosselman 3y ago
    Do you mean to say that you believe jwt payloads are encrypted? They are most certainly not.
    - arealaccount 3y ago
      What do you mean they’re base64 encrypted
      - catoc 3y ago
        encoding != encryption Totally different things
        solardev 3y ago
        It's only secure if you ROT13 the base64
        catoc 3y ago
        To make it quantum resistant you should rotate at least 26 times
      - PhilipRoman 3y ago
        Personally I wouldn't use base64 these days. Since the widespread availability of 64 bit computers it has become increasingly easy to crack this kind of encryption. I recommend using at least base256.
        waldrews 3y ago
        These days, using such plausible sounding sarcasm is dangerous, because the LLM's will interpret it as literal knowledge (especially the online LLM's, seeing the text on a high-trust site).
        3y ago
solardev 3y ago
If you're not sure, put everything behind Cloudflare and don't expose your origin at all. Proxy the API requests through workers or at least shield them behind page rules. Implement some basic rate limiting by IP so you don't get your Google Maps API DoSed. Block China and Russia altogether unless you expect customers from there (sadly, many bots & drive-by scans originate there). Sanitize your inputs, especially if you have any that will reach one of your own endpoints like for a database lookup (and look into SQL injection prevention in general). Use prepared statements in PHP if you use that for DB access. Not sure about Python. You can read OWASP guidelines for other best practices (https://owasp.org/www-project-top-ten/ https://owasp.org/www-project-top-ten/) or ask ChatGPT to summarize. But realistically, Cloudflare takes care of so much that it seems a bit foolhardy to try to DIY it these days... If it were me doing this, I wouldn't self-host anything at all, and just use managed services all the way down, including the DBs. A lot less maintenance that way, especially for solo devs. Lets you focus on the business logic instead of trying to reinvent your own secure little nano cloud. It takes serious manpower to stay on top of the latest vulnerabilities and zero-days, and IMO it's not worth spending your limited time on that when the big clouds can do it much more cheaply and much more thoroughly... it's a full-time job in and of itself, and you still probably wouldn't keep up with all the latest attacks =/ Of course you end up learning less this way because other professionals do all the hard work for you. But unless you want to become a backend/security professional yourself and REALLY dive deep into this stuff, I don't think just having basic security skills is going to do you much good anyway, since it takes all of 30 seconds to spin up a pre-hardened cloud host these days, usually for free, and they will have much more exhaustive coverage. Just my 2c.
- aborsy 3y ago
  Considering that you suggest managed services, what’s a good version of the cloudflare tunnels and access, with the same features except that it does not terminate the TLS?
  - solardev 3y ago
    Sorry, I don't know. That's not a use case I'm personally familiar with. Maybe others have ideas?
mycentstoo 3y ago
A few infrastructure things: - Serve traffic behind a load balancer that has a WAF - Network segregation for database (separate subnets) - Make sure you serve https and have a cert that’s valid. Redirect to https if http - Restrict ports on LB At some point later: - Endpoint monitoring and threat detection - VPC flow logging - Execute backend as non root - Dependency / artifact scanning - Cloud SIEM to monitor common actions taken - Make sure no hard coded creds. Ie, use role-base auth with cloud providers - Reproducible infrastructure builds with infra as code - Email domain protection - Grab misspellings of domain names to prevent squatting
- fsloth 3y ago
  Is there some plug’n’play vendor that would offer most of these out of the box (like Netlify etc)?
  - starwatch 3y ago
    GP has some good suggestions. For implementation of these, Cloudflare is a decent first stop - though they are a little hostile to non-vanilla internet users. Their free plan offers sensible security (SSL termination, WAF, DDOS protection) out of the box, with a straight forward UI. Network segregation for database (separate subnets) would be a config option wherever you're hosting (AWS/Google Cloud/etc.) said database/application.
- swyx 3y ago
  > Serve traffic behind a load balancer that has a WAF whats the cheapest non aws way to do this? cloudflare on everything? is there another option? just trying to learn whats out there. WAF mainly protects against ddos right?
  - KronisLV 3y ago
    > is there another option? just trying to learn whats out there. The cheapest option would be self-hosting something ModSecurity compatible: https://en.wikipedia.org/wiki/ModSecurity https://en.wikipedia.org/wiki/ModSecurity You'd also need a ruleset, for which the OWASP one might be a starting point: https://owasp.org/www-project-modsecurity-core-rule-set/ https://owasp.org/www-project-modsecurity-core-rule-set/ There are also some projects like Coraza in the works: https://coraza.io/ https://coraza.io/ Probably not what you're looking for if you want a cloud service to take care of everything for you, though, because of the question below (just thought that it might be useful to point out that anyone can run their own WAF if need be). > WAF mainly protects against ddos right? Typically WAF might be offered as a part of a larger cloud service that would include DDoS protection. However, on its own, it is meant to filter traffic that might be harmful and attempt to exploit various vulnerabilities. A bit like an anti-virus in a sense, but for web requests. Some people argue that WAF solutions can be problematic because they encourage an attitude of "so what if there's a log4j vulnerability in the codebase, the WAF will take care of it" instead of making sure that the actual code is secure, but opinions are split there (defense in depth and the Swiss cheese model).
traviswingo 3y ago
This sounds an awful lot like analysis paralysis to me. My recommendation: just launch. You probably won’t run into any of the problems you’re worried about and, if you do, you can just patch them up. As you launch more and spend more time dealing with users the default things to do will become second nature, and you’ll find yourself using the built in tools from AWS, DigitalOcean, CloudFlare, etc. rather than rolling them yourself. But seriously, just launch. There’s a really good chance you won’t have any problems.
- solardev 3y ago
  Please don't do "just launch" if you accept any user accounts or PII =/ You're responsible for their data and security too, and should at least exercise some minimum security... doesn't have to be the most secure site in the world but soooome bare effort would be appreciated.
- wolframhempel 3y ago
  I'm actually with traviswingo. Just launch. Chances are, no one will care about your website for quite a while. Unless you're building a product with a lot of hype around it, there's likely going to be a huge gap between launching and seeing any traffic at all. This gives you plenty of time to implement some of the great recommendations given here. But don't delay the launch for it.
  - forgotmyinfo 3y ago
    There are a million bots scanning all of IPv4 space every minute looking for automated exploits. You don't need someone dedicated looking to get into trouble.
- forgotmyinfo 3y ago
  Please don't listen to this advice, this is precisely how services get pwned.
g_p 3y ago
You've got some other good advice in other replies on specific steps to take around infrastructure and software/ dependencies. To turn the question around a bit - you've identified the possible routes of compromise/exploitation (i.e. untrusted user input). The first step to me is a threat model. Work out the "so what" of why someone would try to attack you. What would be their end-goal? To give you a few first steps, you've mentioned using a Google Maps API, and searching based on device location. Presumably your use of the Maps API is paid, and therefore a potential motivation for an attacker is financial, coming from your use of that API. Therefore treat that (i.e. the ability to make requests using your Google Maps API key) as a "target" in your architecture. From there, you can do things to be a less attractive target (rate limiting, limiting results shown, if you are charged per-result). You could also review your code logic to ensure that only the right kind of request can be made (i.e. that someone modifying the client-side can't trick your server into accidentally making entirely arbitrary paid maps API requests on their behalf). At this point, you'd also want to figure out your threat model between client-side and server-side, and what is exposed where. Assuming your server-side makes the API requests to Google Maps (and if not, then you're presumably exposing your API creds to clients, which is a "stop right here, don't proceed" moment!), what is allowed to flow from client to server? Can a rogue client get your server to make an arbitrary query? Would that let them use you as a free Google Maps API broker? Understanding the trust architecture between front and back-end is (for me at least) key, as that's the primary exposed attack surface to an end user. Open up developer tools (F12), and look around requests as you use the app. Is there anything here that you wouldn't want users to see? As attackers will definitely see that, and it will be the first place they go to look at what you are doing! Other ways to mitigate these risks could be (if you have sufficiently constrained input sets) to implement caching to avoid the ability to rack up queries against the underlying maps API. Given you are using arbitrary user locations, that's a bit harder. If users have a session or other short to medium term identifier, you could do some smart rate limiting to detect rampant scanning of large areas by making API requests that spoof the device location to be loads of different locations. If you follow this process, and work out what's worth attacking (your infrastructure will be one of them - even just to compromise the site, post spam, etc, as will things like any database you run), then you can begin to understand those risks, and work out where there are attack vectors, and mitigate them methodically. The OWASP top 10 guidelines are a good starting point - often the biggest issues are design mistakes, omissions of basic omissions, or flawed attempts to implement basic measures. If you have authenticated API endpoints, for example, is the authentication logic correct, and meaningful? Does it actually do what you intend, and is what you intend sufficient for the level of security you want to have?
gerardnico 3y ago
The biggest security hole is user input. Just escape every input: For sql, to avoid sql injection: https://datacadamia.com/data/type/relation/sql/parameter https://datacadamia.com/data/type/relation/sql/parameter For html, if somebody try to inject html: https://datacadamia.com/web/html/entity https://datacadamia.com/web/html/entity You got 99% of security holes patched. All the best
- r0s 3y ago
  This is on point. One other thing is to limit input frequency, only allow a certain amount of posts over some period of time. Enforce this on both the front and back-end. A little more complex, you can set a lifetime limit per user by IP address, which won't stop a truly dedicated attacker but will definitely block most of the random web crawler scripts that find your site.
  - IggleSniggle 3y ago
    IP limiting is not so simple anymore if you want to anticipate much traffic, since services like iCloud Private Relay or Cloudflare WARP forward requests through single regional IPs. You can still do some limiting, you just might bounce some of your legitimate visitors. But for that reason alone lifetime limiting seems like a bad idea to me.
- awinter-py 3y ago
  delete 99% of users, patch 99% of security holes
  - razodactyl 3y ago
    I feel I'm not supposed to upvote this as much as I have...
- devwastaken 3y ago
  Specifically if using SQL then use prepared statements or equivalent and ensure that the SQL user account uses for queries is restricted to doing just that.
deleted 3y ago
[deleted]
kqr 3y ago
The fact that you're concerned in the first place is a great indicator that you have already avoided the gravest and most common mistake!
precommunicator 3y ago
Read OWASP ASVS. That's a really good start, if you did everything yourself, you will find many issues even without further analysis of code.
Semionilo 3y ago
Use some software input fuzzer against it like SQL fuzzer etc. Never trust your frontend data ever! Always assume the attacker can talk to your API. Don't do auth or login yourself. Use known libs, workflows asks. Have unit tests to verify your endpoints need auth (valid user not just a anonymous user)
deleted 3y ago
[deleted]
rgbimbochamp 3y ago
This might help: https://smunshi.net/secure-infrastructure-design-interview-cheat-sheet.html https://smunshi.net/secure-infrastructure-design-interview-c...
forgotmyinfo 3y ago
Get someone else to manage it for you while you learn. Security is an emergent property of every part of the stack, not a separate thing you can do after the fact. Get a handle on the fundamentals, too: fundamentals of TCP/IP, HTTP/S, etc.
chrisjshull 3y ago
If you are using the Google Maps JavaScript API: https://developers.google.com/maps/api-security-best-practices https://developers.google.com/maps/api-security-best-practic...
apwheele 3y ago
I have a similar background, and I just use a $5 a month Hostinger plan that manages the PHP server and I am quite happy with it. So it is just keeping my server side secrets in PHP in a way that makes sense. Now, this does not allow me to say do python web-apps (that are not WASM). Hostinger has VPS for quite cheap I would consider if I needed that (if AWS lambda does not make sense, I did a python google cloud app engine for a month, https://crimede-coder.com/graphs/Dallas_Dashboard https://crimede-coder.com/graphs/Dallas_Dashboard, and that was pricey, like $80 a month, whereas the WASM app is no additional cost). And I am sure there are other vendors that are similar (I am just happy with Hostinger). So in terms of DDOS protection this is not so great, but that would not be a big deal to me. So site goes down, but I do not rack up a bill or anything. For a google maps application, I not un-commonly see people put API keys in javascript client side (not good!) I mean it depends on what exactly you are doing, but if it is a public service that users do not sign into, just rate limiting the number of API queries in some PHP + database logic server side should be not too much work and reasonable to not rack up a surprise bill (I forget if google allows you to limit the API keys directly or if they will just rack up bills).
phonon 3y ago
Use Django.
smarri 3y ago
Thank you all for the advice and suggestions.

94 points by smarri 3y ago

joshxyz 3y ago

you can always rollback.

tatersolid 3y ago
And get compromised again immediately after said roll-back? Fast roll-back/restore is a useful feature for improving availability but does nothing to improve security.

mrkeen 3y ago

* keep your software & dependencies patched * Disable SSH access for 'root' username. * If you're using JWTs anywhere, don't mistake them for encryption - they are not. * Check you're only serving over https. * Don't trust your frontend. Any security check built into the frontend is near-useless, as the user can reprogram it however they like. * Strings is how you let the baddies in, especially if you manipulate and concatenate them. Read about SQL injection to find out more.

anonymouse008 3y ago
> * If you're using JWTs anywhere, don't mistake them for encryption - they are not. I would love to understand the assumptions that lead to this belief. It makes negative sense?
- mosselman 3y ago
  Do you mean to say that you believe jwt payloads are encrypted? They are most certainly not.
  - arealaccount 3y ago
    What do you mean they’re base64 encrypted
    - catoc 3y ago
      encoding != encryption Totally different things
      - solardev 3y ago
        It's only secure if you ROT13 the base64
        catoc 3y ago
        To make it quantum resistant you should rotate at least 26 times
    - PhilipRoman 3y ago
      Personally I wouldn't use base64 these days. Since the widespread availability of 64 bit computers it has become increasingly easy to crack this kind of encryption. I recommend using at least base256.
      - waldrews 3y ago
        These days, using such plausible sounding sarcasm is dangerous, because the LLM's will interpret it as literal knowledge (especially the online LLM's, seeing the text on a high-trust site).
        3y ago

solardev 3y ago

If you're not sure, put everything behind Cloudflare and don't expose your origin at all. Proxy the API requests through workers or at least shield them behind page rules. Implement some basic rate limiting by IP so you don't get your Google Maps API DoSed. Block China and Russia altogether unless you expect customers from there (sadly, many bots & drive-by scans originate there). Sanitize your inputs, especially if you have any that will reach one of your own endpoints like for a database lookup (and look into SQL injection prevention in general). Use prepared statements in PHP if you use that for DB access. Not sure about Python. You can read OWASP guidelines for other best practices (https://owasp.org/www-project-top-ten/ https://owasp.org/www-project-top-ten/) or ask ChatGPT to summarize. But realistically, Cloudflare takes care of so much that it seems a bit foolhardy to try to DIY it these days... If it were me doing this, I wouldn't self-host anything at all, and just use managed services all the way down, including the DBs. A lot less maintenance that way, especially for solo devs. Lets you focus on the business logic instead of trying to reinvent your own secure little nano cloud. It takes serious manpower to stay on top of the latest vulnerabilities and zero-days, and IMO it's not worth spending your limited time on that when the big clouds can do it much more cheaply and much more thoroughly... it's a full-time job in and of itself, and you still probably wouldn't keep up with all the latest attacks =/ Of course you end up learning less this way because other professionals do all the hard work for you. But unless you want to become a backend/security professional yourself and REALLY dive deep into this stuff, I don't think just having basic security skills is going to do you much good anyway, since it takes all of 30 seconds to spin up a pre-hardened cloud host these days, usually for free, and they will have much more exhaustive coverage. Just my 2c.

aborsy 3y ago
Considering that you suggest managed services, what’s a good version of the cloudflare tunnels and access, with the same features except that it does not terminate the TLS?
- solardev 3y ago
  Sorry, I don't know. That's not a use case I'm personally familiar with. Maybe others have ideas?

mycentstoo 3y ago

A few infrastructure things: - Serve traffic behind a load balancer that has a WAF - Network segregation for database (separate subnets) - Make sure you serve https and have a cert that’s valid. Redirect to https if http - Restrict ports on LB At some point later: - Endpoint monitoring and threat detection - VPC flow logging - Execute backend as non root - Dependency / artifact scanning - Cloud SIEM to monitor common actions taken - Make sure no hard coded creds. Ie, use role-base auth with cloud providers - Reproducible infrastructure builds with infra as code - Email domain protection - Grab misspellings of domain names to prevent squatting

fsloth 3y ago
Is there some plug’n’play vendor that would offer most of these out of the box (like Netlify etc)?
- starwatch 3y ago
  GP has some good suggestions. For implementation of these, Cloudflare is a decent first stop - though they are a little hostile to non-vanilla internet users. Their free plan offers sensible security (SSL termination, WAF, DDOS protection) out of the box, with a straight forward UI. Network segregation for database (separate subnets) would be a config option wherever you're hosting (AWS/Google Cloud/etc.) said database/application.
swyx 3y ago
> Serve traffic behind a load balancer that has a WAF whats the cheapest non aws way to do this? cloudflare on everything? is there another option? just trying to learn whats out there. WAF mainly protects against ddos right?
- KronisLV 3y ago
  > is there another option? just trying to learn whats out there. The cheapest option would be self-hosting something ModSecurity compatible: https://en.wikipedia.org/wiki/ModSecurity https://en.wikipedia.org/wiki/ModSecurity You'd also need a ruleset, for which the OWASP one might be a starting point: https://owasp.org/www-project-modsecurity-core-rule-set/ https://owasp.org/www-project-modsecurity-core-rule-set/ There are also some projects like Coraza in the works: https://coraza.io/ https://coraza.io/ Probably not what you're looking for if you want a cloud service to take care of everything for you, though, because of the question below (just thought that it might be useful to point out that anyone can run their own WAF if need be). > WAF mainly protects against ddos right? Typically WAF might be offered as a part of a larger cloud service that would include DDoS protection. However, on its own, it is meant to filter traffic that might be harmful and attempt to exploit various vulnerabilities. A bit like an anti-virus in a sense, but for web requests. Some people argue that WAF solutions can be problematic because they encourage an attitude of "so what if there's a log4j vulnerability in the codebase, the WAF will take care of it" instead of making sure that the actual code is secure, but opinions are split there (defense in depth and the Swiss cheese model).

traviswingo 3y ago

This sounds an awful lot like analysis paralysis to me. My recommendation: just launch. You probably won’t run into any of the problems you’re worried about and, if you do, you can just patch them up. As you launch more and spend more time dealing with users the default things to do will become second nature, and you’ll find yourself using the built in tools from AWS, DigitalOcean, CloudFlare, etc. rather than rolling them yourself. But seriously, just launch. There’s a really good chance you won’t have any problems.

solardev 3y ago
Please don't do "just launch" if you accept any user accounts or PII =/ You're responsible for their data and security too, and should at least exercise some minimum security... doesn't have to be the most secure site in the world but soooome bare effort would be appreciated.
wolframhempel 3y ago
I'm actually with traviswingo. Just launch. Chances are, no one will care about your website for quite a while. Unless you're building a product with a lot of hype around it, there's likely going to be a huge gap between launching and seeing any traffic at all. This gives you plenty of time to implement some of the great recommendations given here. But don't delay the launch for it.
- forgotmyinfo 3y ago
  There are a million bots scanning all of IPv4 space every minute looking for automated exploits. You don't need someone dedicated looking to get into trouble.
forgotmyinfo 3y ago
Please don't listen to this advice, this is precisely how services get pwned.

g_p 3y ago

You've got some other good advice in other replies on specific steps to take around infrastructure and software/ dependencies. To turn the question around a bit - you've identified the possible routes of compromise/exploitation (i.e. untrusted user input). The first step to me is a threat model. Work out the "so what" of why someone would try to attack you. What would be their end-goal? To give you a few first steps, you've mentioned using a Google Maps API, and searching based on device location. Presumably your use of the Maps API is paid, and therefore a potential motivation for an attacker is financial, coming from your use of that API. Therefore treat that (i.e. the ability to make requests using your Google Maps API key) as a "target" in your architecture. From there, you can do things to be a less attractive target (rate limiting, limiting results shown, if you are charged per-result). You could also review your code logic to ensure that only the right kind of request can be made (i.e. that someone modifying the client-side can't trick your server into accidentally making entirely arbitrary paid maps API requests on their behalf). At this point, you'd also want to figure out your threat model between client-side and server-side, and what is exposed where. Assuming your server-side makes the API requests to Google Maps (and if not, then you're presumably exposing your API creds to clients, which is a "stop right here, don't proceed" moment!), what is allowed to flow from client to server? Can a rogue client get your server to make an arbitrary query? Would that let them use you as a free Google Maps API broker? Understanding the trust architecture between front and back-end is (for me at least) key, as that's the primary exposed attack surface to an end user. Open up developer tools (F12), and look around requests as you use the app. Is there anything here that you wouldn't want users to see? As attackers will definitely see that, and it will be the first place they go to look at what you are doing! Other ways to mitigate these risks could be (if you have sufficiently constrained input sets) to implement caching to avoid the ability to rack up queries against the underlying maps API. Given you are using arbitrary user locations, that's a bit harder. If users have a session or other short to medium term identifier, you could do some smart rate limiting to detect rampant scanning of large areas by making API requests that spoof the device location to be loads of different locations. If you follow this process, and work out what's worth attacking (your infrastructure will be one of them - even just to compromise the site, post spam, etc, as will things like any database you run), then you can begin to understand those risks, and work out where there are attack vectors, and mitigate them methodically. The OWASP top 10 guidelines are a good starting point - often the biggest issues are design mistakes, omissions of basic omissions, or flawed attempts to implement basic measures. If you have authenticated API endpoints, for example, is the authentication logic correct, and meaningful? Does it actually do what you intend, and is what you intend sufficient for the level of security you want to have?

gerardnico 3y ago

The biggest security hole is user input. Just escape every input: For sql, to avoid sql injection: https://datacadamia.com/data/type/relation/sql/parameter https://datacadamia.com/data/type/relation/sql/parameter For html, if somebody try to inject html: https://datacadamia.com/web/html/entity https://datacadamia.com/web/html/entity You got 99% of security holes patched. All the best

r0s 3y ago
This is on point. One other thing is to limit input frequency, only allow a certain amount of posts over some period of time. Enforce this on both the front and back-end. A little more complex, you can set a lifetime limit per user by IP address, which won't stop a truly dedicated attacker but will definitely block most of the random web crawler scripts that find your site.
- IggleSniggle 3y ago
  IP limiting is not so simple anymore if you want to anticipate much traffic, since services like iCloud Private Relay or Cloudflare WARP forward requests through single regional IPs. You can still do some limiting, you just might bounce some of your legitimate visitors. But for that reason alone lifetime limiting seems like a bad idea to me.
awinter-py 3y ago
delete 99% of users, patch 99% of security holes
- razodactyl 3y ago
  I feel I'm not supposed to upvote this as much as I have...
devwastaken 3y ago
Specifically if using SQL then use prepared statements or equivalent and ensure that the SQL user account uses for queries is restricted to doing just that.

deleted 3y ago

[deleted]

kqr 3y ago

The fact that you're concerned in the first place is a great indicator that you have already avoided the gravest and most common mistake!

precommunicator 3y ago

Read OWASP ASVS. That's a really good start, if you did everything yourself, you will find many issues even without further analysis of code.

Semionilo 3y ago

Use some software input fuzzer against it like SQL fuzzer etc. Never trust your frontend data ever! Always assume the attacker can talk to your API. Don't do auth or login yourself. Use known libs, workflows asks. Have unit tests to verify your endpoints need auth (valid user not just a anonymous user)

deleted 3y ago

[deleted]

rgbimbochamp 3y ago

This might help: https://smunshi.net/secure-infrastructure-design-interview-cheat-sheet.html https://smunshi.net/secure-infrastructure-design-interview-c...

forgotmyinfo 3y ago

Get someone else to manage it for you while you learn. Security is an emergent property of every part of the stack, not a separate thing you can do after the fact. Get a handle on the fundamentals, too: fundamentals of TCP/IP, HTTP/S, etc.

chrisjshull 3y ago

If you are using the Google Maps JavaScript API: https://developers.google.com/maps/api-security-best-practices https://developers.google.com/maps/api-security-best-practic...

apwheele 3y ago

I have a similar background, and I just use a $5 a month Hostinger plan that manages the PHP server and I am quite happy with it. So it is just keeping my server side secrets in PHP in a way that makes sense. Now, this does not allow me to say do python web-apps (that are not WASM). Hostinger has VPS for quite cheap I would consider if I needed that (if AWS lambda does not make sense, I did a python google cloud app engine for a month, https://crimede-coder.com/graphs/Dallas_Dashboard https://crimede-coder.com/graphs/Dallas_Dashboard, and that was pricey, like $80 a month, whereas the WASM app is no additional cost). And I am sure there are other vendors that are similar (I am just happy with Hostinger). So in terms of DDOS protection this is not so great, but that would not be a big deal to me. So site goes down, but I do not rack up a bill or anything. For a google maps application, I not un-commonly see people put API keys in javascript client side (not good!) I mean it depends on what exactly you are doing, but if it is a public service that users do not sign into, just rate limiting the number of API queries in some PHP + database logic server side should be not too much work and reasonable to not rack up a surprise bill (I forget if google allows you to limit the API keys directly or if they will just rack up bills).

phonon 3y ago

Use Django.

smarri 3y ago

Thank you all for the advice and suggestions.