Q:

Checar se usuário alterou requisição POST

Tenho uma aplicação javascript que roda do lado cliente, nesta aplicação o usuário pode disparar eventos que se comunicam com o servidor do meu site através de uma requisição POST. Porém, preciso garantir que o usuário não tenha forjado os dados preparados por esta minha aplicação. Por exemplo, o usuário pode interceptar a conexão antes que ela saia de sua máquina e alterar os atributos das variáveis que estou passando por POST. 
Em outro exemplo: podemos supor que esta variável seja uma pontuação e a informação real é de creditar 10 pontos na conta de um determinado usuário, porém o mesmo pode interceptar esta comunicação, alterá-la e enviar uma falsa requisição para que o servidor credite 1.000 pontos. Não se trata de um erro de validação, pois ambos os valores são numéricos e por isto serão aceitos no servidor, também não se trata de SSL, pois o próprio usuário está agindo de má fé, alterando os dados antes que estes saiam de sua máquina. Como posso validar estes dados para saber se houve manipulação? Já vi alguns sites utilizando-se de hash para isso, mas não entendi bem como isso pode ser feito.

A:

Informações sensíveis nunca devem depender do client-side¹ porque criptografia em Javascript é inútil.
A transparência oferecida por navegadores atuais tornam todo o seu código e informações legíveis e alteráveis em poucos clicks. Isso não significa que navegadores antigos tornavam a web mais segura. Ao contrário, antigamente era mais fácil um desenvolvedor acreditar que sua aplicação estava segura quando utilizando qualquer tipo de complicação como encryptação JavaScript, aplicação compilada (Flex/Actionscript), entre outros.
Tokens CSRF poderão te auxiliar a evitar que alguém forje uma chamada ao seu servidor a partir de outra fonte (cURL, CORS, etc), mas não irão garantir que as demais informações sendo trafegadas sejam íntegras como esperado.
Você pode utilizar uma combinação de CSRF com SSL/TLS para encriptar a conexão entre o cliente e o servidor, evitando possíveis adulterações nos arquivos javascript e garantindo que a resposta veio de sua aplicação, mas ainda assim não justifica depender do client-side fornecer informações sensíveis.
Atualização
Respondendo ao comentário, qualquer mecanismo de segurança que você possa pensar utilizando Javascript em browsers já foi pensada antes, não trata-se de uma falta de ideia, mas sim da mecânica como o Javascript funciona no navegador. Mesmo que você crie uma chave pública pelo servidor para que o cliente utilize essa chave e você garanta que a informação foi criptografada utilizando uma chave válida, o usuário final ainda possui a informação antes e depois de criptografá-la. A mesma facilidade de forjar dados que não representam a realidade com e sem tal mecanismo é a mesma, pois o cliente só ira adulterar a informação antes dela ser criptografada.
Se você está dependendo de informação segura do seu client, você precisa repensar sua forma de aplicação.

Qual ação o cliente realiza que lhe garante direito a pontos?
Quem tem obrigação financeira para com a criação dessa pontuação?
São multiplas ações, cada qual com um valor de pontuação diferente?
Uma mesma ação poderá acarretar em pontuações diferentes?
Uma pessoa é capaz de adquirir pontos enquanto off-line e sincronizar quando on-line?

Cada pergunta que você conseguir pensar sobre seu modelo poderá especificar melhor onde está seu problema. Se seu cliente ganha pontos off-line, você precisa pensar em formas de cupons, tais que um cupom tem um código gerado que torna-o matematicamente improvável que alguém conseguirá "achá-lo" aleatoriamente. Se seu cliente ganha pontos ao realizar uma compra, talvez seja de competência do próprio estabelecimento garantir a autenticidade da informação. Se uma ação específica só é capaz de gerar uma quantidade de pontos específico, essa pontuação pode ser armazenada do lado do servidor.

