The easiest way to understand the difference is to ask one question: what do you need to do with the original data later? If you only need to verify it, hash it. If you need to recover it, encrypt it. If you only need to show part of it, mask it. If you are protecting passwords with a hash, salt them. If you only need to change the format for transport or storage, encode it and decode it later.
Many security incidents begin with a small misunderstanding. A developer sees a Base64 string and assumes it is encrypted. A product team masks a card number in the user interface but still sends the full value in the API response. A backend stores passwords with a fast hash and no work factor. A logging pipeline forwards authorization headers to a SIEM. None of these mistakes require a complex exploit. They happen when teams use the right-sounding control for the wrong job.
This guide gives a practical, customer-ready explanation of hashing, encryption, masking, salting, encoding, and decoding. It also explains where these choices matter most in API security, including API sensitive data exposure, PII and PCI detection in API traffic, and API token and secrets leakage detection.
The quick answer: each control has a different purpose
Hashing turns data into a fixed-size value that should not be reversed. It is best when the original value is not needed later, such as password verification or integrity checks.
Encryption protects data so it can be safely recovered later by someone or something with the right key. It is best for confidential data that must remain usable, such as stored files, tokens, addresses, backups, or sensitive internal fields.
Masking hides part of a value from people, screens, logs, reports, or tools. It is best for reducing exposure while still letting humans recognize the record, such as showing only the last four digits of an account number.
Salting is not a standalone protection method. It is an input added to a password before hashing so the same password does not produce the same stored hash across users or systems.
Encoding changes data into another representation so systems can handle it safely. Decoding reverses that representation. Encoding is useful, but it is not secrecy.
Hashing vs encryption vs masking vs salting vs encoding: side-by-side comparison
The table below is the fastest way to explain the difference to developers, security teams, compliance teams, and business stakeholders.
| Method | Main goal | Reversible? | Uses a secret key? | Best use cases | Common mistake |
|---|---|---|---|---|---|
| Hashing | Verify or fingerprint data without storing the original | No | Usually no | Password verification, file integrity, deduplication, tamper checks | Using fast hashes such as plain SHA-256 for passwords |
| Encryption | Protect confidentiality while keeping data recoverable | Yes, with key | Yes | Tokens, files, sensitive fields, backups, internal payloads | Encrypting data but storing keys next to the data |
| Masking | Hide data from display, logs, exports, and lower-trust users | Depends | Not necessarily | Support screens, reports, API logs, SIEM events, dashboards | Masking the UI but still returning full data in the API response |
| Salting | Make password hashes unique and harder to attack at scale | Not applicable | No, salt is usually stored | Password hashing and some key derivation workflows | Using one shared salt for all users or treating salt as encryption |
| Encoding | Represent data in a safe format for systems and protocols | Yes | No | Base64, URL encoding, HTML encoding, JSON escaping, percent encoding | Assuming encoded values are secret because they look unreadable |
| Decoding | Return encoded data to its original representation | Yes | No | Reading encoded payloads, URLs, headers, files, and messages | Decoding untrusted input without validation and context-aware handling |
Notice the pattern: hashing and salting are mostly about verification and password safety; encryption is about recoverable confidentiality; masking is about controlled visibility; encoding and decoding are about format compatibility.
How each method works in plain English
Hashing: prove a match without storing the original
A hash function takes an input and produces an output that looks like a fixed-length fingerprint. A strong cryptographic hash should make it impractical to determine the original input from the output alone. That makes hashing useful when the system only needs to compare values.
Password storage is the most common example, but it is also where teams make the most dangerous mistakes. Current guidance from NIST and OWASP emphasizes that passwords should be stored in a form resistant to offline attacks, using salted password hashing with a work factor. In practice, that means modern password hashing schemes such as Argon2id, scrypt, bcrypt, or PBKDF2 rather than a simple fast hash.
For passwords, the goal is not just to hide the password. The goal is to make password guessing expensive if an attacker obtains the password database. A fast hash can be calculated millions or billions of times quickly on modern hardware. A password hashing scheme intentionally slows each guess down and can also use memory cost to make large-scale guessing harder.
Encryption: keep data confidential but recoverable
Encryption transforms readable data into ciphertext. A system with the correct key can decrypt it back into the original value. That reversibility is the main difference between encryption and hashing.
Encryption is the right choice when the application needs the original value later. Examples include encrypted documents, stored OAuth refresh tokens, private customer fields, database backups, internal service messages, or data stored in object storage. The hard part is not only choosing an algorithm. It is key management: where keys live, who can use them, how rotation works, how access is audited, and what happens during incident response.
Encryption does not automatically solve exposure. If an API decrypts a field and returns it to the wrong user, the exposure is still real. If logs capture plaintext after decryption, the logs become sensitive. If the key is stored beside the encrypted data, the protection may be weak. Encryption is powerful, but it must be paired with authorization, runtime visibility, and careful handling of decrypted values.
Masking: reduce what people and tools can see
Masking changes what is displayed or shared. It may show part of a value, replace characters, remove fields, or present a safe substitute. A support user may see ****1234 instead of a full card number. A log pipeline may store user_email_masked instead of the full email. A report may show a customer region instead of a full address.
Masking is often misunderstood because it can happen at many layers. Masking in the UI does not mean masking in the API. Masking in logs does not mean masking in exports. Masking in analytics does not mean masking in the database. Security teams should check each place where data moves, not only the place where humans see it.
Salting: make password hashes unique
A salt is a unique random value used with password hashing. Two users may choose the same password, but if each user has a different salt, the stored password hashes should be different. This helps defend against precomputed lookup tables and makes bulk password attacks harder.
A salt is usually stored next to the hash. That surprises some teams, but it is normal. The salt is not an encryption key. Its value comes from uniqueness and randomness, not secrecy. A pepper, by contrast, is a separate secret used as an additional layer in some password storage designs and must be protected separately.
Encoding and decoding: change format, not trust
Encoding turns data into a representation that another system can safely handle. URL encoding helps put special characters into URLs. HTML encoding helps display characters safely in a page context. Base64 helps represent binary data as text. JSON escaping helps preserve structure inside JSON strings.
Decoding reverses the process. That is why encoding is not encryption. If a value can be decoded without a secret, it should not be treated as confidential. Encoded tokens, encoded identifiers, and encoded payloads can still contain sensitive data.
Practical examples that make the differences easier to understand
Security controls become clearer when mapped to real data flows. The examples below show how the same piece of information may require different treatment depending on its purpose.
User password
Store a salted password hash using a modern password hashing scheme. Do not encrypt the password for normal login flows because the application should not need to recover it.
OAuth refresh token
Encrypt at rest because the system may need to use the token later. Also restrict access, rotate when needed, and detect token leakage in API traffic and logs.
Card number in support screen
Mask the display, such as showing only the last four digits. Do not return the full value in the API response if the user interface does not need it.
Binary document in JSON
Encode the binary value, often with Base64, so it can travel through JSON. Encrypt it separately if it contains confidential information.
The same principle applies to logs. A security event can be useful without exposing the raw sensitive value. For example, an API security platform may record that a token-like value appeared in a response, the endpoint involved, the user role, the destination, and the severity without storing the token itself.
Example data-handling decision Data: user password Need: verify login later Correct control: salted password hashing Do not: encrypt and decrypt the password for login Data: OAuth refresh token Need: recover for authorized refresh flow Correct control: encryption with protected keys Do not: log the plaintext token Data: account number in support UI Need: identify record without exposing the full value Correct control: masking, field-level access, audit trail Do not: send the full value to every browser session Data: binary payload in JSON Need: transport safely as text Correct control: encoding Do not: treat encoded data as confidential
Runtime API Security Considerations
APIs are where these choices become operational. A database field may be encrypted at rest, but the API can still expose it in a response. A password may be hashed in the identity database, but the login API may still leak plaintext credentials into debug logs. A token may be encrypted in storage, but forwarded in a header to the wrong integration. A masked value may look safe in a portal while the backend returns the complete object.
This is why teams need API runtime visibility and request and response inspection, not only static design reviews. Runtime inspection helps answer practical questions: Which endpoints return PII? Which responses include PCI-like fields? Are authorization headers forwarded to downstream services? Are tokens or secrets appearing in logs? Are encoded values hiding sensitive data? Are object identifiers being manipulated in ways that suggest BOLA or IDOR API security risk?
Security signals to monitor
Sensitive data exposure
Watch for PII, PCI data, secrets, tokens, and excessive response fields in API traffic, especially when a response includes more data than the interface needs.
Decoded payload risk
Review Base64, URL encoded, and serialized payloads when they appear in parameters, headers, cookies, or JSON fields. Encoded does not mean safe.
Token and secrets leakage
Detect API keys, bearer tokens, session identifiers, authorization headers, and credentials in requests, responses, errors, and SIEM-forwarded events.
Behavior and abuse patterns
Combine data exposure findings with API behavior analytics, enumeration signals, replay attempts, parameter tampering, and business logic abuse patterns.
How this affects DevSecOps and SOC teams
DevSecOps teams usually care about prevention: which control should be used, where it should be implemented, and how it should be tested. SOC teams care about detection and response: where sensitive data appeared, whether it was accessed by the wrong identity, whether the event was repeated, and whether the blast radius is growing.
Both teams need the same evidence. They need to know the endpoint, method, user or service identity, request path, response fields, data classification, authentication context, and whether the value was plaintext, masked, encoded, encrypted, or hashed. This is also why SIEM-ready events and API security incident response playbooks matter. Without structured evidence, teams can waste time arguing whether something was “really exposed.”
| API scenario | What can go wrong | Better control | Runtime signal |
|---|---|---|---|
| Login request | Password appears in application logs or API traces | Redact or omit credentials before logging | Credential-like field in request body |
| User profile response | Full PII returned to a low-privilege client | Field-level authorization and response minimization | Unexpected PII in response |
| Support dashboard API | UI masks value but API returns full value | Mask or omit at the API layer | Masked UI with unmasked backend response |
| Integration webhook | Encoded payload contains sensitive data | Encode for format, encrypt for confidentiality | Base64 or URL encoded sensitive fields |
| Token storage | Recoverable token stored without strong protection | Encryption, key separation, rotation, access audit | Token-like value in storage path or logs |
For broader evaluation, connect this topic to API response data leakage, API data exfiltration detection, API forensics, API threat hunting, API abuse detection, and alert fatigue reduction. A mature API security program does not only block obvious attacks. It also identifies when sensitive values are moving through places they should never reach.
A simple decision framework for choosing the right method
Use this framework whenever a team is deciding how to protect a value in an application, API, log, event stream, report, database, or integration.
1. Do you need the original value later?
If no, consider hashing. Password verification, integrity checks, and certain privacy-preserving lookups usually fit here. If yes, hashing is probably wrong because you cannot recover the original value from a proper hash.
2. Who should be able to recover the original value?
If only trusted systems should recover it, use encryption and protect the keys separately. Think beyond algorithms: key storage, access control, rotation, audit logging, and emergency revocation are part of the control.
3. Who only needs a partial view?
If users, support agents, analysts, or dashboards only need recognition, use masking or redaction. Do not send the full value to the client and rely on the browser to hide it.
4. Is the problem only transport format?
If the data needs to fit inside a URL, JSON field, HTML page, or text-based protocol, encoding may be enough for formatting. It is not enough for confidentiality.
5. Is this a password?
If it is a password, treat it as a special case. Use a suitable password hashing scheme with a unique salt and a work factor. Store algorithm and cost metadata so the system can migrate over time.
Decision flow Need to verify only? Use hashing. If password: use salted password hashing with a work factor. Need to recover the original? Use encryption. Protect keys separately from encrypted data. Need to show only part of a value? Use masking or redaction. Apply it at the API, log, export, and UI layers as needed. Need to move data through a text format? Use encoding. Add encryption if confidentiality is required. Need to investigate API exposure? Inspect requests, responses, headers, logs, decoded payloads, and SIEM events.
Implementation checklist for applications and APIs
Use this checklist during architecture review, secure code review, API onboarding, proof of value, vendor evaluation, or customer success reporting.
Password storage
Confirm passwords are not stored in plaintext or reversible encryption. Use a modern password hashing scheme, unique salts, work factors, and migration metadata.
Key management
Confirm encryption keys are separated from encrypted data, access is limited, key use is audited, and rotation is planned before an incident.
API responses
Confirm APIs return only the fields each client needs. Check for excessive data exposure, broken object property authorization, and unmasked backend responses.
Logs and SIEM
Confirm logs do not store plaintext passwords, tokens, authorization headers, secrets, raw payment data, or decoded payloads that should be redacted.
Encoded input
Confirm encoded data is decoded safely, validated in context, and not trusted simply because it was transformed. Watch for nested or double encoding.
Runtime evidence
Confirm security teams can see where sensitive values appear across requests, responses, downstream calls, logs, and alerts without increasing exposure.
Questions to ask during an API security review
- Does this endpoint return sensitive fields that the client does not need?
- Are tokens, API keys, session IDs, or authorization headers visible in logs?
- Are passwords handled only by the authentication flow and stored with salted password hashing?
- Can support users retrieve full sensitive values when a masked view would be enough?
- Are encoded fields decoded and inspected before authorization, validation, and logging decisions?
- Can the SOC trace sensitive data exposure from the endpoint to the identity and downstream service?
- Does the incident response workflow distinguish between encrypted, masked, hashed, and plaintext exposure?
Common mistakes to avoid
Mistake 1: “It is Base64, so it is safe”
Base64 is easy to decode. It is useful for formatting, not secrecy. If a Base64 value contains a token, password, email address, or payment-related field, that value is still sensitive.
Mistake 2: “We masked it in the browser”
Browser masking is not enough if the API response still contains the full value. Attackers, insiders, browser extensions, debugging tools, proxies, and logs may still see the raw field.
Mistake 3: “We encrypted the database, so the API is safe”
Database encryption can protect against certain storage risks, but it does not prevent an authorized application from decrypting and returning sensitive data to the wrong user. API authorization and response minimization still matter.
Mistake 4: “A hash is always safe”
Hashing is not automatically safe. Passwords need password hashing schemes designed to slow guessing attacks. Hashing low-entropy values, such as predictable IDs or phone numbers, can still allow guessing unless the design accounts for it.
Mistake 5: “Salt must be secret”
A password salt should be unique and random, but it is normally stored with the hash. Do not confuse salt with a key. If you add a pepper, that pepper is secret and must be protected separately.
Mistake 6: “Security tools should store every raw value for investigation”
Security teams need useful evidence, not unnecessary exposure. A better approach is to capture structured context, classify the data, preserve safe samples when needed, and avoid storing raw credentials or secrets.
How to keep the guidance current
Cryptographic guidance changes over time as hardware improves, algorithms age, and standards evolve. For password storage, review the current NIST Digital Identity Guidelines and OWASP Password Storage Cheat Sheet. For encryption design, review the OWASP Cryptographic Storage Cheat Sheet and your own regulatory requirements. For APIs, align implementation reviews with the OWASP API Security Top 10 and your organization's data classification rules.
Do not treat this as a one-time checklist. Cost factors, key rotation practices, log redaction rules, token handling, and API response minimization should be reviewed as systems change. New endpoints, new integrations, new AI agents, new mobile clients, and new partner APIs can all introduce fresh exposure paths.
Conclusion: choose based on the job, not the buzzword
Hashing, encryption, masking, salting, encoding, and decoding are all useful, but they are not interchangeable. Hash when you only need verification. Encrypt when trusted systems must recover the original value. Mask when people and tools do not need to see the full value. Salt password hashes so identical passwords do not create identical stored hashes. Encode when the issue is format, not secrecy.
For API security, the decision is not only about storage. It is about where data appears at runtime: requests, responses, headers, logs, traces, SIEM events, exports, dashboards, and downstream services. The strongest data protection strategy combines correct cryptographic choices with runtime visibility, least privilege, sensitive data detection, and practical incident response.
Frequently asked questions
What is the difference between hashing and encryption?
Hashing is one-way and is used when you only need to verify that a value matches, such as a password. Encryption is reversible with the right key and is used when the original value must be recovered later, such as a document, address, token, or payment-related field that a trusted system must read.
Is encoding the same as encryption?
No. Encoding changes data into another format so systems can store or transmit it safely. Anyone who understands the encoding can decode it. Encryption protects confidentiality with keys. Base64, URL encoding, and HTML encoding are not security controls by themselves.
What is salting in password hashing?
Salting means adding a unique random value to each password before hashing it. The salt helps prevent precomputed lookup attacks and makes identical passwords produce different stored hashes. A salt is normally stored with the password hash; it is not the same as an encryption key.
Should passwords be encrypted or hashed?
Passwords should normally be stored with a modern password hashing scheme, not reversible encryption. Current guidance from NIST and OWASP emphasizes salted, work-factor-based password hashing for password verification, because applications should not need to recover a user's original password.
What is data masking used for?
Data masking hides part or all of a sensitive value in screens, logs, reports, support tools, and exports. It is useful for reducing exposure, but it does not always remove the original data from the backend. Masking should be paired with access control, logging discipline, and runtime monitoring.
Can masked data still be sensitive?
Yes. Masked data can still be sensitive when enough characters remain to identify a person, account, card, token, session, or business object. Teams should review masked values in context, especially in API responses, SIEM events, customer support tools, and analytics exports.
When should encryption be used in APIs?
Use encryption when sensitive data must remain confidential but still be recovered by an authorized system. Common examples include stored tokens, private documents, payment-related fields, backup data, and internal service payloads. Encryption requires strong key management and careful access control.
When should hashing be used in APIs?
Use hashing when the application only needs comparison, lookup, deduplication, tamper detection, or integrity verification without recovering the original value. Examples include password verification, request signing, file integrity checks, and privacy-preserving identifiers when designed carefully.
Why is Base64 not secure?
Base64 is only an encoding format. It makes binary or structured data easier to move through text-based systems, but it does not protect confidentiality. A Base64 value can be decoded without a secret key, so sensitive values must not be treated as safe simply because they look unreadable.
How does this topic relate to API sensitive data exposure?
APIs often move passwords, tokens, session identifiers, account numbers, addresses, PII, PCI data, and business objects through requests and responses. Choosing the wrong control can expose sensitive data in logs, responses, integrations, caches, or downstream tools.
What should DevSecOps teams check in API logs?
DevSecOps teams should check whether logs contain plaintext passwords, tokens, API keys, personal data, payment data, raw authorization headers, excessive response bodies, or decoded values that should have stayed masked, encrypted, tokenized, or omitted.
What is the safest way to choose between hashing, encryption, masking, salting, and encoding?
Start with the business need: verify, recover, display, store, transmit, or investigate. Then choose the least-exposing control that satisfies that need. Passwords usually need salted hashing, recoverable secrets need encryption, displays need masking, and transport formatting needs encoding.
Protect sensitive API data before it becomes an incident
Ammune helps teams inspect API requests and responses, identify sensitive data exposure, detect token and secrets leakage, reduce alert noise, and produce security evidence that DevSecOps, SOC, partners, and executives can understand.