application_security/data_protection

26 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Return only necessary fields from database queries

Only return the specific database fields needed for the operation to prevent information disclosure. User tables typically contain sensitive fields like passwords, social security numbers, email addresses and birth dates. Create sanitization functions (e.g., `sanitizeUser()`) that return only required fields like id, username, and fullName. Apply this principle to all objects retrieved from the database.

Rails sensitive files to protect or exclude

The following files may contain sensitive information and should be excluded or carefully managed: /config/database.yml (production credentials), /config/initializers/secret_token.rb (session cookie hashing secret), /db/seeds.rb (seed data including bootstrap admin users), /db/development.sqlite3 (may contain real data).

Sensitive data must not appear in URLs

Passwords, security tokens, and API keys should not appear in the URL, as this can be captured in web server logs. In `POST`/`PUT` requests, sensitive data should be transferred in the request body or request headers. In `GET` requests, sensitive data should be transferred in an HTTP Header.

XMLEnc encryption for SAML assertions

Assertions may be encrypted via XMLEnc to prevent disclosure of sensitive attributes after transportation. This counters theft of user authentication information attacks.

Strong encryption for SAML elements

Ensure all SAML elements in the chain use strong encryption. Consider deprecating support for insecure XMLEnc algorithms such as RSA-1.5.

Public object storage not recommended

Public object storage should only be used for public, non-sensitive, generic resources. This storage approach provides threat actors additional reconnaissance into a cloud environment, and any data stored in this configuration for any period must be considered publicly accessed or leaked to the public.

Encryption definition and purpose

Encryption transforms data (plaintext) into an unreadable format (ciphertext) using a secret key. The purpose is confidentiality: only authorized parties with the key can read the data. Encryption is reversible through decryption with the correct key. Encryption types include symmetric (same key for encryption and decryption) and asymmetric (public and private keys).

Hashing definition and purpose

Hashing transforms data into a fixed-size string (a hash or digest) using a mathematical function. The purpose is integrity: a small change in the input results in a completely different hash. Hashing is one-way and non-reversible. Hashing is used for password storage with salt and for verifying file integrity. Examples include SHA-256, Argon2, and bcrypt.

Digital signatures definition and mechanism

Digital signatures use asymmetric cryptography to provide proof of the origin and integrity of a message. They provide authenticity and non-repudiation, proving who sent the message and that it was not altered. The mechanism requires the sender to sign a hash of the message with their private key; the receiver verifies it with the sender's public key. Examples include JWT signatures and GPG signatures.

Cold start & execution context security: assume runtime is not clean, avoid storing secrets in globals, protect against side-channel leaks

Do not assume the function runtime context is clean between invocations. Avoid storing secrets or temporary sensitive data in global or static variables. Protect against side-channel leaks through timing differences or leftover files in the /tmp directory. For sensitive workloads, enforce single-use execution environments if the platform supports it.

Bad practice: hardcoded secret in global variable across Lambda invocations

Do not store hardcoded secrets in global variables because the variable persists across invocations: SECRET_KEY = "hardcoded-secret" is unsafe.

Good practice: fetch Lambda secrets at runtime from vault

Fetch secrets fresh at each Lambda invocation using a secrets library or vault, not from hardcoded or global variables. Example: secret = get_secret("db-password") retrieves the secret dynamically within the handler.

Secrets management for serverless: fetch at runtime from vault, use ephemeral credentials, rotate automatically

Fetch secrets at runtime from a vault or caching extension, not from platform-level function configuration such as Lambda Environment Variables. Use ephemeral credentials (STS, workload identity federation). Rotate secrets automatically.

AWS Lambda Parameters and Secrets Extension requirement

To use the AWS Lambda Parameters and Secrets Extension for secret retrieval, the extension must be added and enabled for the function (for example, as a Lambda layer). Without it, HTTP requests to localhost:2773 will fail.

AWS Lambda secret retrieval via Parameters and Secrets Extension (Python)

Python code to retrieve a secret using the AWS Lambda Parameters and Secrets Extension local endpoint. The extension provides an HTTP endpoint on port 2773 at http://localhost:2773/secretsmanager/get?secretId={encoded_name}. Authentication requires the X-Aws-Parameters-Secrets-Token header set to the AWS_SESSION_TOKEN environment variable. The function sends a GET request with a 3-second timeout and parses the JSON response to extract the SecretString field, which is then parsed as JSON to retrieve the actual secret. Raises RuntimeError if AWS_SESSION_TOKEN is missing and raises Exception if the response status is not 200.

Protect transaction data confidentiality during client-server communication

The transaction authorization process must protect the privacy of transaction data that the user will authorize during steps where transaction data is sent to the server and where the user verifies transaction data.

Encryption requirements for user data in transit and storage

Any online platform handling user identities, private information or communications must be secured with strong cryptography. User communications must be encrypted in transit and storage. User secrets such as passwords must be protected using strong, collision-resistant hashing algorithms with increasing work factors. To protect data in transit, use TLS/SSL best practices including verified certificates, adequately protected private keys, strong ciphers only, informative warnings to users, and sufficient key lengths. Private data must be encrypted in storage using keys with sufficient lengths under strict access conditions both technical and procedural. User credentials must be hashed regardless of whether they are encrypted in storage.

Prevent IP address leakage through third-party content

Any application that hosts external third-party content such as avatars, signatures or photo attachments must take into account preventing user IP address leakage. If it is possible to embed third-party external domain images in a user's feed or timeline, an adversary might use it to discover a victim's real IP address by hosting the image on their domain and watching for HTTP requests. Web developers should consider giving users the option of blocking external content as a precaution. This applies mainly to social networks and forums but can also apply to web-based email where images can be embedded in HTML-formatted emails. Most email clients and providers block loading of third-party content by default, providing better privacy and anonymity protection.

XML digital signatures for message integrity

For XML data, use XML digital signatures to provide message integrity using the sender's private key. This signature can be validated by the recipient using the sender's digital certificate (public key).

Strong encryption for messages with sensitive data

Messages containing sensitive data must be encrypted using a strong encryption cipher. This could be transport encryption or message encryption. Messages containing sensitive data that must remain encrypted at rest after receipt must be encrypted with strong data encryption, not just transport encryption.

Zero Trust response to data exfiltration

Use data-level access controls with real-time behavior analysis instead of relying only on network monitoring and DLP at perimeter.

Endpoint protection: full disk encryption

Encrypt all data on the device.

Data protection: classify data

Label data by sensitivity level.

Data protection: use encryption

Protect data whether it is stored or moving with proper cryptographic storage.

Data protection: prevent data loss

Monitor and block unauthorized data transfers.

Legacy system challenge: no encryption

Many older systems send data in plain text because they were designed for internal networks that were considered secure. Adding encryption often requires significant changes to both the systems and the network infrastructure they depend on.

Give your agent this brain