2.10 Data Security, Validation & Ethics Flashcards
What’s the duty of a web developer?
To design and build applications that are not only secure but ethically responsible.
Is there ever foolproof security?
No. Multiple layers of security have become the necessity, ensuring that even if one method is breached, there’s always a backup.
In April 2016, the European Union passed the General Data Protection Regulation (GDPR). What does it pertain to?
It pertains to the processing of personal data of users within the EU (as well as regulations for companies based in an EU country, even if their users are outside the EU). While the GDPR regulations are EU based, it has become somewhat of an international standard for most application developers. Since the protections are for EU users in general, a company beyond the EU may still fall under the regulation’s scope
- general principle outlined in the GDPR: Lawfullness, Fairness, Transparency
“Lawfulness,” here, simply means that all data must be in accordance with the guidelines of the GDPR. “Fairness” means that data must be collected truthfully and in good faith. “Transparency” refers to keeping users informed when and for what purposes their data is being collected.
- general principle outlined in the DGPR: Purpose Limitation
Organizations should only collect data for a specified, limited, and legitimate purpose. In other words, a company can’t say it’s collecting data for one thing (e.g., to populate a social network profile) but actually be collecting it for another purpose (e.g., to provide consulting firms) without explicitly informing its users.
- general principle outlined in the DGPR: Data Minimization
Organizations shouldn’t collect more data than they need to meet their stated purposes. This ensures malicious entities can’t acquire extraneous information upon breaching your application’s security. It also makes it easier to maintain accurate data
- general principle outlined in the DGPR: Accuracy
All data should be up-to-date and accurate, and organizations should take reasonable steps to erase or rectify inaccurate data (e.g., by prompting users to update their data).
- general principle outlined in the DGPR: Storage Limitation
Similarly, organizations shouldn’t retain personal user data any longer than is absolutely required. Data should be consistently reviewed to ensure its necessity. This also helps to keep data accurate.
- general principle outlined in the DGPR: Integrity & Confidentiality
This guideline revolves around keeping data secure and confidential (i.e., not accessible by malicious entities). This is also what the rest of this Exercise will concern itself with. Keeping data secure usually involves encryption methods, which can protect data even if it’s stolen.
What is the “same-origin policy”?
The same-origin policy is a feature within browsers that restricts cross-origin HTTP GET requests, in other words, GET requests from a different domain (or “origin”)
Unless otherwise specified, if you make a GET request from one domain to another domain, what type of error will your receive?
No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘…’ is therefore not allowed access.
Disadvantages of the “same-origin policy”
While the same-origin policy is perfect for protecting users on the web, it does create a few unwanted problems when it comes to working with APIs. By restricting requests from one domain to another, it also prohibits domains from making requests to APIs on a different server (i.e., with a different origin/domain). For instance, think of a real-estate website. Oftentimes, these types of websites will load maps of houses by making requests to the Google Maps API; under the same-origin policy, these types of requests would be restricted, as the Google Maps API is located on a different domain/origin (“maps.google.com”) than the real-estate website.
Cross-Origin Resource Sharing (CORS)
What CORS does is extend HTTP requests, giving them new headers that include their domain. The receiving server can then identify where the request is coming from and allow or disallow the request from going through.
When the server receives this request, it checks whether the included domain is allowed, then sends back an HTTP response with a new header of its own, indicating that the requesting domain was permitted:
“Access-Control-Allow-Origin: [list of permitted domains or a wildcard for all domains]”
For example, if an HTTP request were sent to a server from “test.com,” the server’s response could include either an asterisk, which allows access from all domains:
Access-Control-Allow-Origin: *
Or, a list of specifically allowed domains, for instance:
Access-Control-Allow-Origin: https://www.test.com http://www.test.com https://site.mdn.net http://site.mdn.net https://static.sitename.net http://static.sitename.net
what’s the command to install cors?
npm install cors
Once you installed cors, what do you have to do after in your code?
const cors = require('cors'); app.use(cors());
What’s a general rule for allowing requests?
You should only allow requests from domains that need your API.
For instance, if your application’s frontend were hosted separately from the API, you’d want to ensure the domain hosting your frontend was granted access.
The fewer domains that have access to your API, the more secure it (and the data it provides access to) will be.
Why is it considered bad practice to use an asterisk * ?
Because that would grant access to all domains.
Why are http requests unsecure?
Normal “http” requests are sent in plain text format—in other words, unencrypted text. If a malicious entity were to intercept them, they’d have complete access to all of the information contained within. This is especially dangerous in public WiFi spaces such as airports and coffee shops, where persons of nefarious intent can more easily intercept these requests, putting any data you might fill in on websites (credit card information, your name and address, etc.) at risk.
Why are https requests more secure than HTTP?
With the “https” prefix, messages sent between the browser and the domain are encrypted using a security protocol called Secure Sockets Layer, or SSL. Requests that have been encrypted using SSL can’t be read without an encryption key. This keeps any data inside safe from prying eyes, even if the requests themselves happen to be intercepted. An SSL certificate is required to create an SSL connection. Oftentimes, if you host your website or web application on a server, the hosting provider will include (for a price) an SSL certificate as part of its hosting package. Registering one requires information about the identity of your website and your company.
Which two cryptographix keys are created along when the SSL certificate is created?
Private key and public key
What is encryption?
Encryption is the process of turning data into a series of unreadable characters, which can then be decrypted, or reversed back to their original form, by way of a key. This ensures data can only be read by those with the proper permission (i.e., those with the key).
What is hashing?
Hashing is the process of turning data into a string of text or numbers that (with a good hashing algorithm) can’t be turned back into the original string. Once the data has been hashed, it’s no longer accessible to anyone