An integration team proposes “encrypting” API JSON by Base64-encoding bodies on HTTP without TLS. Which principle of API encryption does that miss beyond hiding bytes poorly?
Select an answer to reveal the explanation.
Short Explanation
Hiding the recipe in pig Latin does not stop someone from rewriting it mid-trip. TLS both conceals and protects integrity; Base64-on-HTTP does neither for real.
Full Explanation
Base64 on HTTP without TLS obscures bytes only from casual glance; it provides neither confidentiality against a real observer nor integrity against tampering. The encryption principle missed is that TLS supplies confidentiality and integrity so tampering with the body or headers can be detected—not merely rearranging bytes. Municipal API JSON carrying tokens needs cryptographic protection, not homemade encoding.
Claiming Base64 on HTTP fully replaces certificate hostname verification fails: encoding does not authenticate the server. Asserting homemade encoding provides MACsec-layer integrity invents a capability Base64 lacks. Saying only SNMP community strings need integrity while API bodies do not fails modern API threat models—body and header tampering can change tenant IDs, amounts, or authz decisions.
Exam caveat: compression+encryption and HTTP/2 concerns are advanced; the scored point is TLS vs encoding theater. Signed JWTs inside cleartext HTTP still leak claims and are not a TLS substitute.
Operational check: in design review, reject “Base64 encryption” proposals, require HTTPS, and demonstrate a MitM lab where Base64 bodies are trivially decoded and modified while TLS prevents silent modification.